# Odd SignTool signing / verification error

**URL:** <https://www.finalbuilder.com/forums/t/odd-signtool-signing-verification-error/3690>\
**Category:** Bugs\
**Created:** [March 17, 2018, 11:57am UTC](https://www.finalbuilder.com/forums/t/odd-signtool-signing-verification-error/3690 "2018-03-17T11:57:26Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![mikef74](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/m/dc4da7/32.png) [@mikef74](https://www.finalbuilder.com/forums/u/mikef74)\
**Post date:** [March 17, 2018, 11:57am UTC](https://www.finalbuilder.com/forums/t/odd-signtool-signing-verification-error/3690/1 "2018-03-17T11:57:26Z")

</div>

I’ve been at this for 13 hours now and am losing my mind. I can’t say that it’s definitely FinalBuilder’s issue, but it’s such a tricky issue I really can’t say who’s camp this falls into.   
  
 In an offshoot branch of my project, I’m unable to sign one particular DLL of mine. Well, it appears to sign just fine, but I’ve learned from past experience to always verify the signatures and timestamps. Well, for whatever reason this one particular DLL has decided it doesn’t want to be signed anymore. I did a whole bunch of stuff to try to get to the bottom of it. I tried different signing/timestamp providers. I turned off all asynchronous operations around signing. I tried varies versions of SignTool. Running the project in FinalBuilder directly works, but running it via TeamCity (and again, only for this particular branch) causes issues. I’ve rebooted several times. I’ve cleaned the output folder. I’ve uninstalled a recently installed Windows Update. I even made slight changes to my DLL’s source code just so it had something slightly different to sign. This is a big DLL, about 35MB. But the same size as the one in the other branches. People sign multi-gigabyte installer files all the time, so I can’t imagine a 35MB DLL would cause it to choke.   
  
 The error when viewing the digital signature in Windows Explorer is: The digital signature of the object is malformed. For technical detail, see security bulletin MS13-098. That bulletin is a dead end about some changes from Microsoft about 3-4 years ago. The error when trying to use SignTool to verify the signature is “WinVerifyTrust returned error: 0x80096011”.   
  
 If anyone has any ideas or insights, I’d love to hear them.   
  
 Thanks,   
 -Mike

---

<div class="post-metadata">

**Author:** ![mikef74](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/m/dc4da7/32.png) [@mikef74](https://www.finalbuilder.com/forums/u/mikef74)\
**Post date:** [March 17, 2018, 11:58am UTC](https://www.finalbuilder.com/forums/t/odd-signtool-signing-verification-error/3690/2 "2018-03-17T11:58:26Z")

</div>

Sorry, this is the latest edition of FB8 (as well as the prior release) on Windows Server 2012 R2.

---

<div class="post-metadata">

**Author:** ![mikef74](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/m/dc4da7/32.png) [@mikef74](https://www.finalbuilder.com/forums/u/mikef74)\
**Post date:** [March 18, 2018, 12:05pm UTC](https://www.finalbuilder.com/forums/t/odd-signtool-signing-verification-error/3690/3 "2018-03-18T12:05:01Z")

</div>

Looking at the visible details of the certificate available from Windows Explorer, everything looks fine (both on the machine and with the DLL copied off the build server). Everything except that malformed error message. I can’t tell if this was an error in signing, or some really obscure validation issue that affects both signtool and Windows Explorer.

---

<div class="post-metadata">

**Author:** ![mikef74](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/m/dc4da7/32.png) [@mikef74](https://www.finalbuilder.com/forums/u/mikef74)\
**Post date:** [March 18, 2018, 12:42pm UTC](https://www.finalbuilder.com/forums/t/odd-signtool-signing-verification-error/3690/4 "2018-03-18T12:42:27Z")

</div>

I temporarily removed a large embedded resource from my DLL, taking it’s size down to 18MB. Now it works fine. This is driving me crazy. There’s just something odd about it running under FB8+TeamCity that causes SignTool to mangle the file during the signing process (yet, returns success messages).

---

<div class="post-metadata">

**Author:** ![Vincent](https://www.finalbuilder.com/forums/user_avatar/www.finalbuilder.com/vincent/32/938_2.png) [@Vincent](https://www.finalbuilder.com/forums/u/Vincent)\
**Post date:** [March 18, 2018, 10:08am UTC](https://www.finalbuilder.com/forums/t/odd-signtool-signing-verification-error/3690/5 "2018-03-18T10:08:53Z")

</div>

I can’t say I have seen anything like this before. If it was occuring with other branches or just with FinalBuilder I’d suspect FinalBuilder or perhaps something with the code signing certificate itself.   
  
 Permissions perhaps? Is the TeamCity agent running under the same user that you tested with FinalBuilder?   
  
 I hate to say it, but antivirus is my goto offender for “something strange happening here”. I sometimes suggest looking at it as a last resort, and I’m rarely surprised when it does turn out to be the cause!

---

<div class="post-metadata">

**Author:** ![gabriel.landau](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/g/d9b06d/32.png) [@gabriel.landau](https://www.finalbuilder.com/forums/u/gabriel.landau)\
**Post date:** [July 11, 2025, 10:27pm UTC](https://www.finalbuilder.com/forums/t/odd-signtool-signing-verification-error/3690/6 "2025-07-11T22:27:30Z")

</div>

@mikef74 Did you ever figure this out? I may have just come across a similar situation with an “unverifiable” EXE. Signing works as usual, but verification always returns:

> The digital signature of the object is malformed. For technical detail, see security bulletin MS13-098.

On a different machine, I removed the signature with `signtool remove`, then re-signed it using a different key - same error. I tried multiple builds of `signtool` (`22621.1778` and `26100.4188`) to no avail. The failures continue even after disabling `EnableCertPaddingCheck` in the registry then rebooting.

I suspect it has something to do with the PE layout. Did you use Microsoft’s `link.exe` to link the DLL, or something else?
