bug: Dlib file not found at: .\Tools\Azure.CodeSigning.Dlib.dll

[ixm7]

Bug Report

Version:

2.0.0.0

Current behavior:

Getting the following error (across 5 attempts):
Attempt 1: Using timestamp server 'East US' (https://eus.codesigning.azure.net)
Exception during attempt 1: Dlib file not found at: .\Tools\Azure.CodeSigning.Dlib.dll

The dll is located in the default install location:
C:\Program Files\Michael Morten Sonne\SignToolGUI\Tools\Azure.CodeSigning.Dlib.dll
And .NET SDK 8.0.415 is installed.

Expected behavior:
The dll should be recognized

Steps to reproduce:

Using Trusted Signing via Azure. Made sure I'm signed in.
Specified the Signing Account Name and the Certificate Profile.
In the End Points dialog, enabled only 'East US'

[michaelmsonne]

Hi @ixm7 ,

Thanks for the report here! Tested it via the tool on my own laptop right now, but tested some senarios based on the steps you provided here, it works fine for me:

Also when Eest US is the only one enabled:

(The time used for signing, I got promted to sign-in)

All loks file in my logs too.

[ixm7]

I noticed that your image shows Signtool location as: C:\users...
While mine shows: C:\Program Files...

Perhaps you'd be able to replicate the bug by testing using a machine where the tool was installed using a normal installation procedure.

[michaelmsonne]

I see the error on a other client else not tested on (tested the installer and so on in Windows Sandbox) - intresting find @ixm7 - I will see what I can find out, as I see the error is happening even if running the tool as administrator (in C:\Program Files\Michael Morten Sonne\SignToolGUI)

Attempt 1: Using timestamp server 'East US' (https://eus.codesigning.azure.net)
Signing attempt 1/3...
Version: 1.0.68
Unhandled managed exception
Azure.RequestFailedException: Service request failed.
SignTool Error: An unexpected internal error has occurred.
Status: 404 (Not Found)
Headers:
Date: Tue, 04 Nov 2025 16:05:39 GMT
Connection: keep-alive
Strict-Transport-Security: REDACTED
mise-correlation-id: REDACTED
x-azure-ref: REDACTED
X-Cache: REDACTED
Content-Length: 0
at Azure.CodeSigning.CertificateProfileRestClient.SignAsync(String codeSigningAccountName, String certificateProfileName, SignRequest body, String xCorrelationId, String clientVersion, CancellationToken cancellationToken)
at Azure.CodeSigning.CertificateProfileClient.StartSignAsync(String codeSigningAccountName, String certificateProfileName, SignRequest body, String xCorrelationId, String clientVersion, CancellationToken cancellationToken)
at Azure.CodeSigning.Dlib.Core.DigestSigner.SignAsync(UInt32 algorithm, Byte[] digest, SafeFileHandle safeFileHandle, CancellationToken cancellationToken)
at Azure.CodeSigning.Dlib.Core.DigestSigner.Sign(UInt32 algorithm, Byte[] digest, SafeFileHandle safeFileHandle)
Error information: "Error: SignerSign() failed." (-2147467259/0x80004005)
Timestamp failed using 'East US': SignTool Error: An unexpected internal error has occurred.
Attempt 2: Using timestamp server 'East US' (https://eus.codesigning.azure.net)

A workaround is to install it in another location for now.

Not got this reports else, so intresting what´s changed..

[ixm7]

Another issue I noticed is that the dialog doesn't remember last used options such as:
Signing Account Name, Certificate Profile, and Files to Sign.

[michaelmsonne]

I have pinged the product team for Trusted Signing about the error here, as it looks like internal the bug happens in the lib.

Regarding the features you mention for remembering Signing Account Name, Certificate Profile and files to Sign - I can add that if that is usefull to have - not thinked about that 😊

Thanks for the feedback.

[ixm7]

The tool already remembers the endpoint options. In the same way, users would expect remembering process options.

This would also facilitate calling the tool via a command line (defaulting to the saved settings).
Signing via a Command Line call is a high-priority feature.

[ixm7]

The error:
Dlib file not found at: .\Tools\Azure.CodeSigning.Dlib.dll
is an exception triggered in your code, not on Azure's side:

[michaelmsonne]

The error: Dlib file not found at: .\Tools\Azure.CodeSigning.Dlib.dll is an exception triggered in your code, not on Azure's side:

It fine runs here in that combination via the installer:

Config:

[Program]
SignToolPath=C:\Program Files\Michael Morten Sonne\SignToolGUI\Tools\signtool.exe
TimestampProvider=0
TimestampURL=http://timestamp.acs.microsoft.com
CertificatePassword=
CertificatePath=
CertificateType=TrustedSigning
ValidatePasswordOnSave=1
[Timestamp]
ServerConfiguration={"TimestampServers":[{"DisplayName":"West Europe","Url":"https://weu.codesigning.azure.net","IsEnabled":false,"Priority":1,"TimeoutSeconds":30},{"DisplayName":"North Europe","Url":"https://neu.codesigning.azure.net","IsEnabled":false,"Priority":2,"TimeoutSeconds":30},{"DisplayName":"West US 2","Url":"https://wus2.codesigning.azure.net","IsEnabled":false,"Priority":3,"TimeoutSeconds":30},{"DisplayName":"West Central US","Url":"https://wcus.codesigning.azure.net","IsEnabled":false,"Priority":4,"TimeoutSeconds":30},{"DisplayName":"East US","Url":"https://eus.codesigning.azure.net","IsEnabled":true,"Priority":5,"TimeoutSeconds":30}]}
[TrustedSigning]
AccountName=sonnes
CertificateProfile=michael
[Files]
ToSign=["C:\Users\MichaelMortenSonne\Downloads\Add-PIMGroups.ps1"]

If I look at the debugger via VS also, the path´s looks fine here.

[michaelmsonne]

The tool already remembers the endpoint options. In the same way, users would expect remembering process options.

This would also facilitate calling the tool via a command line (defaulting to the saved settings). Signing via a Command Line call is a high-priority feature.

2 things to this one:

• I will add the missing saves of the config to the tool in the next release - stay tuned for that, and thanks for thefeedback @ixm7

• Regarding the signing via a Command Line - this tool is made as a GUI (as the name of the tool also states), for a warpper around the allready known Command Line tools (signtool.exe and the Trusted Siging libs) - ss if this for my releases, I will not implement that for now.

[michaelmsonne]

The error: Dlib file not found at: .\Tools\Azure.CodeSigning.Dlib.dll is an exception triggered in your code, not on Azure's side:

Added some more logging for what I get when I run the tool (installed via installer and same config):

04-11-2025 20.23.13 - [EventID 3001] Information Timestamp attempt 1: Using server 'East US' at https://eus.codesigning.azure.net
04-11-2025 20.23.13 - [EventID 3032] Information Calling Trusted Signing via arguments: 'sign /fd sha256 /tr "http://timestamp.acs.microsoft.com" /td sha256 /dlib ".\Tools\Azure.CodeSigning.Dlib.dll" /dmdf "C:\Users\MichaelMortenSonne\AppData\Local\Temp\tmp47A3.json" "C:\Users\MichaelMortenSonne\Downloads\Add-PIMGroups.ps1"'
04-11-2025 20.23.13 - [EventID 3033] Information Resolved DLIB location: 'C:\Program Files\Michael Morten Sonne\SignToolGUI\Tools\Azure.CodeSigning.Dlib.dll'
04-11-2025 20.23.13 - [EventID 3033] Information Resolved DMDF location: 'C:\Users\MichaelMortenSonne\AppData\Local\Temp\tmp47A3.json' | Working directory: 'C:\Program Files\Michael Morten Sonne\SignToolGUI'
04-11-2025 20.23.13 - [EventID 3010] Information Starting signing attempt 1/3 for file: Add-PIMGroups.ps1
04-11-2025 20.23.15 - [EventID 3002] Information Timestamp successful using server 'East US' in 1,81 seconds

I see the path reslove like it should.

I have build a pre-release build you are welcome to install (2.1.0.0) and share me the log: https://github.com/michaelmsonne/SignToolGUI/releases/tag/2.1.0.0-dev1

[ixm7]

I installed the new version.
It still generates the following error:
File signing failed after 3 attempts. Last error: Dlib file not found at: .\Tools\Azure.CodeSigning.Dlib.dll

Consider trying to locate the file using the full default path:
C:\Program Files\Michael Morten Sonne\SignToolGUI\Tools\Azure.CodeSigning.Dlib.dll
instead of the relative path:
.\Tools\Azure.CodeSigning.Dlib.dll

Or at least try the full default path if the relative path is throwing that exception. The logic is that perhaps the current folder is not what you expect it to be in the current context of the running application.

[ixm7]

The relative path is relative to the current working directory. It may not be the application directory.

So consider changing the code to build the path using something like:
AppDomain.CurrentDomain.BaseDirectory + "Tools\Azure.CodeSigning.Dlib.dll" ;

[michaelmsonne]

Hmm strange it works differently based on what I see when I test it and the output I getting for the .dll...
I will change the code, thanks for the hint here.

[michaelmsonne]

The relative path is relative to the current working directory. It may not be the application directory.

So consider changing the code to build the path using something like: AppDomain.CurrentDomain.BaseDirectory + "Tools\Azure.CodeSigning.Dlib.dll" ;

Thanks for the hint - tested, and looks for what I can see fine 💪