none
Signing (signtool.exe) : EXEC : error information: "Error: Store::ImportCertObject() failed." (-2146893792/0x80090020) RRS feed

  • Question

  • Hello,

    I'm having this weird problem with signing dll's using signtool.exe. The weird thing is that sometimes it works and sometimes it doesn't.

    I originally had it in VS 2017 when we sign using the postbuild event, but when I use VS Command prompt I can reproduce it..... sometimes.

    When I add 5 (or more) lines like this (with different dll's to sign) in a bat-file it works sometimes and sometimes not:

    "C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe" sign /f [Path for the pfx] /p [Password pfx] "[dll to sign]"

    Originally there was a timestamp as well (/t), but for troubleshooting I omitted it.

    When I launch this bat-file in "Developer Command prompt for VS 2017" I usually get:
    Done Adding Additional Store

    Successfully signed: [dll to sign]

    But sometimes I get the error 

    SignTool Error: An unexpected internal error has occurred.
    Error information: "Error: Store::ImportCertObject() failed." (-2146893792/0x80090020)

    With 5 dll's sometimes they get all signed, but we need to sign over 100 dll's. This never works.
    I couldn't find much on the problem (closest link is this ).

    I just don't understand why it works one time and when I retry it doesn't work anymore, and after another retry it works again.

    All files concerning the signing (the signtool.exe, the pfx and the dll to sign) are on my local system.

    I checked the version of my SDK and it's the latest (10.0.17763.132).
    The problem originated after using a new pfx-file with a new password.

    Any help would be greatly appreciated :)

    Kind regards,

    Bart

    Monday, December 10, 2018 11:32 AM

Answers

  • We were experiencing the exact same problem and I found the possible cause and a better solution than signing multiple times until it succeeds.

    When exporting the certificate as a pfx file, a "new" option was added in Windows 10, "Enable certificate privacy". This option is checked by default.

    This option did not exist when we exported our old certificate that works fine. We exported the new certificate again but unchecked this option and now everything works!

    IMO, this is a bug in Microsoft's signtool.exe.


    Friday, June 14, 2019 4:07 PM

All replies

  • Hi Bart,

    >>SignTool Error: An unexpected internal error has occurred. Error information: "Error: Store::ImportCertObject() failed." (-2146893792/0x80090020)

    Check the following similar issues and workaround:

    Error signing an MSI package, what's going on?

    SignTool Error: An unexpected internal error has occurred. (0x80080209)

    SignTool unexepected internal error

    Regards,

    Stanly


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, December 11, 2018 3:04 AM
    Moderator
  • Hello Stanly,

    Thank you for your reply.

    I checked out the three links you gave, but none worked.

    Link 1) I tried the solution from this link, but it didn't help. Just as an extra remark: the errorcode was not 100% the same (-2146885630/0x80092002 vs -2146893792/0x80090020).

    Link 2) The solution there was the use of a different signtool.exe. I didn't use the same signtool.exe as the one the link mentioned so I changed it into "C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\[x86/x64]\signtool.exe". It didn't help.

    Link 3) The problem was that the user was corrupt. I don't think this is the problem because my colleague has the same problem. The KB also says that you should get an error (warning) when you log on with the corrupt user (if I read correctly). Which I don't get.

    In my search for a solution I never read that it sometimes works and sometimes it doesn't (with the identical same command, so the same pfx, password and dll to sign). And you can't do much wrong/different by (re)starting a bat-file with e.g. 10 signings.

    I'll discuss the problem with some more colleagues when they return from holiday and will document further findings/solutions. Any help is still appreciated.

    Kind regards,

    Bart

    Tuesday, December 11, 2018 9:20 AM
  • Hi all,

    Extra test info.

    1. Using timeout. A colleague suggested that it might be the system not releasing a file/lock/… on time and to add a timeout after every line (in the bat-file). This didn't solve the problem. I used a timeout of 1, 3 and 10 seconds (should be more then enough I suppose).
    2. Manually executing signcommand (not through bat-file). When I open the developer prompt of VS and I paste this command:"C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe" sign /f [Path for the pfx] /p [Password pfx] "[dll to sign]" and I repeat it about 15-20 times fast after each other (using UP-key+Enter) I also get the error.
    3. Starting "Developer Command prompt for VS 2017" as administrator doesn't help as well.
    4. Nothing is added to the event viewer.
    5. I added a wrong path (by accident) as [dll to sign] and tested it. I usually got the error "SignTool Error: File not found", but sometimes I get the Store::ImportCertObject() failed." (-2146893792/0x80090020) error.
    6. Three of my colleagues have the same problem on their own local pc's (same pfx file, same and different dll's to sign).

    So far the update.

    Just to be clear: I'm having this Store::ImportCertObject() failed." (-2146893792/0x80090020) error in Visual Studio (post-build event) and I want it fixed there. By using the manual input in the command prompt and using the bat-file I can reproduce it.

    Kind regards,

    Bart

    Wednesday, December 12, 2018 12:03 PM
  • Hi Bart,

    I have already submitted this question to a more professional team, please be patient.

    Thanks for your understanding.

    Regards,

    Stanly


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, December 14, 2018 8:30 AM
    Moderator
  • Hi Stanley,

    Thx a lot. Just one more piece of info: we gave the problem to one of our consultants and he did let me check a few things (he's currently working on the problem, but has very limited time).

    One of the things he asked to check was the properties of a signed dll and see if it had a tab "Digital Signatures" and to verify what was in it. There was such a tab, but the Digital algoritm was "SHA1" and it should have been "SHA256".
    So I changed the signing command to:
    "C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe"    sign /f %PfxFile% /p %Password% /tr %TimestampURL% /td SHA256 /fd sha256 %1

    The problem was still not solved, but it might be helpful for other ppl trying to help (or having the same problem).

    Kind regards,
    Bart

    Friday, December 14, 2018 10:37 AM
  • ***Update***

    Our external consultant gave us two work arounds:

    1. Test if the signing failed and do it again
    2. Use Powershell to sign

    I tried the first option and it works, except that Visual Studio keeps saying that the build failed :(

    This is what I wrote in the bat-file which gets called from the postbuild event (not directly, we first call VsDevCmd.bat):

    <

    @call %SignCommand%
    IF %ERRORLEVEL% NEQ 0 (
    echo Second attempt
    @call %SignCommand%
    )
    IF %ERRORLEVEL% NEQ 0 ( echo Second attempt failed)
    IF %ERRORLEVEL% EQU 0 (
    echo Signing should be ok. 
    REM Not needed (I think), but just being sure. Doesn't help anyway, still "failed" :@
    EXIT /B 0
    )

    >

    The build logging outputs this (when I rebuild a subproject):
    <

    ...

    10>EXEC : error information: "Error: Store::ImportCertObject() failed." (-2146893792/0x80090020)
    10>EXEC : SignTool error : An unexpected internal error has occurred.
    10>  Second attempt
    10>  Done Adding Additional Store
    10>  Successfully signed: [dll we wanted to sign]
    10> 
    10>  Signing should be ok.

    ========== Rebuild All: 8 succeeded, 2 failed, 0 skipped ==========

    >

    The errorlist shows the errors on the projects with the ["Error: Store::ImportCertObject() failed." (-2146893792/0x80090020)]-error.

    Because the log says "Singing should be ok." I conclude that this bat-file returns 0 (%ERRORLEVEL% is zero).

    The only thing I can come up with is that the signtool.exe somehow keeps track of an error and Visual Studio picks that up. Or I'm doing something wrong in my script :$

    This is just a workaround.

    The original problem is still present: the signing should work every time or never (if there is something wrong with the certificate or a bad parameter passed to the signtool.exe or whatever).

    I suppose the real problem is with the signtool.exe, but I would love to have this workaround with the batfile to stop saying the build failed (because, eventually, it didn't).

    Any help would be greatly appreciated.

    Kind regards,

    Bart

    Thursday, December 27, 2018 10:44 AM
  • Hi Bart,

    Sorry for the late reply.

    About the problem, the best thing to do to get to the root cause it to run out tracing tool on it, which will allow met to debug the problem to why this 0x80090020 error is being given to you.

    I have attached a link to down load the tool and also below are instructions on how to take the trace.

    PartnerTTDRecorder_x86_x64.zip

    HOW TO COLLECT A TIME TRAVEL TRACE:

    Just in case there could be a problem, create a restore point first.  If you cannot log on to the machine anymore due to the problem with the tracing tool, you can restore the system to the restore point at the boot up using F11.  Also make sure that you can add a key under the following registry key remotely as you can remove the tracing tool from logonui.exe that way as well: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. To remove the tracing tool remotely, just remove "debugger" value under LogonUI.exe key.

    Please create a "Time Travel Trace" of the executable where the problem is happening, and zip and send the resultant .run file and .out files to me.

    If a normal dump is like a snapshot, a time travel trace is like a movie of your program demonstrating the problem. I am able to debug it like the problem is happening locally on my computer.

    The .run is the debug trace of your program, and is usually larger than 100MB. The .out file contains information that could be useful if the tracer is unable to create a trace.

    PRIVATE INFORMATION NOTICE:

    You must assume that all the information in the memory of the target process will be included in the .run file, including any passwords or any other sensitive information that the process contains. If you can reproduce the problem without sensitive information in the memory of your process then please do so. If you know that the memory of the process will contain sensitive information then please let me know.

    Download TTT_x86_x64_external.zip by logging on to file sharing portal using the link in the mail that was sent to you. The file may not show up immediately since it takes some time to propagate to the public facing server. If it is not there within 30 minutes please let me know.

    Unzip the zip file and you will use either x86\tttracer.exe or x64\tttracer.exe, depending upon whether the operating system is 32-bit or 64-bit.

    1. unzip TTT_x86_x64_external.zip to a directory
    2. Open an elevated administrator CMD prompt and cd to where you unziped the tool, and then to the x64 directory if the machine is x64, otherwise x86.
    3. "tttracer -initialize".
    4. Create C:\output folder.
    5. (a). if your program is NOT already running: "tttracer -out C:\output -dumpfull -onLaunch myapp.exe". (b). if your program is already running: "tttracer -out C:\output -dumpfull -attach <pid of myapp.exe>".
    6. reproduce the problem
    7. "tttracer -stop all".
    8. "tttracer -delete all".
    9. Zip c:\output folder and upload to your file transfer workspace.  You should have received an automated email with a link to access the workspace.

    Also please send me the .pdb files of your application with full debug info and preferably the code associated with this part of your application.

    Please try to be running tttracer.exe for a little time as possible in order to capture the repro. The reason I ask this is because I would like to minimize the size of the resultant .run file, since they larger they get, the slower they are to debug, and so it will take a lot longer to get to a solution. If the trace has to run for more than a few minutes, then you should trace to a ring buffer instead in order to keep the trace file to a reasonable size, for example:

    "tttracer  -dumpfull -ring -maxfile 2000 -attach <pid>", where pid is the pid of the program to trace, which you can get from taskmgr.exe.

    You will need to stop the trace before the part that contains the repro is overwritten. The best way to do this is to put code in your program or another program that detects the problem has happened, and then launch "tttracer -stop all", which stops all traces on your computer.

    "Max file size (MB)" specifies the size of the ring buffer.

    When tracing to a ring buffer you have to stop the tracing as soon as the problem happens so that the problem is captured and then not overwritten. It may not be practical to wait around for the problem to happen. In this case, you will need to have some programmatic way to detect that the problem has happened, and then programmatically launch tttracer.exe with this command line: [ tttracer.exe -stop all ]. In this way you can capture the problem happening in the trace file, and it will not be over written in the ring buffer.

    Regards,

    Stanly


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, December 31, 2018 7:29 AM
    Moderator
  • Hello, We are currently experience the same problem as you did, and I'm hoping that you can share some information on how you solved this issue.

    We have a slightly different setup, where we run a powershell script that uses msbuild and signtool to create installers on our build server, but the random failure occurs on my machine as well. So far I haven't seen it happen when building in visual studio.

    /Anders

    Tuesday, May 21, 2019 9:51 AM
  • Hi Dumoking,

    We didn't really find a clean solution. We do a "Rebuild" where we call the signtool.exe and if that fails we execute the same call to the signtool.exe. I wrote (part of?) the script above somewhere.

    So far we never had a fail twice. The solutions doesn't build this way (no packaging because of errors).

    But if you do a "Build" after the "Rebuild" it works fine (because he skips everything that didn't change, so he skips everything).

    Hope this helps a bit.

    Kind regards,

    Bart

    Tuesday, May 21, 2019 11:13 AM
  • We were experiencing the exact same problem and I found the possible cause and a better solution than signing multiple times until it succeeds.

    When exporting the certificate as a pfx file, a "new" option was added in Windows 10, "Enable certificate privacy". This option is checked by default.

    This option did not exist when we exported our old certificate that works fine. We exported the new certificate again but unchecked this option and now everything works!

    IMO, this is a bug in Microsoft's signtool.exe.


    Friday, June 14, 2019 4:07 PM
  • Hi Brian,

    I don't have time for the moment to check this, but thanks for the information.

    I'll set the response as Answer ;)

    Kind regards,

    Bart


    Tuesday, June 18, 2019 1:08 PM