Aufruf von SignTool über ShellExecuteEx - SSL Bibliothek nicht gefunden!

[Mavarik]

Hallo Zusammen!

Ich verwende ShellExecuteEx um das Windows Signtool aus dem SDK aufzurufen.

Das hat mal geklappt - ich gehe davon aus, dass ein Windows Update etwas geändert hat...

Aktuelle bekomme ich von Aufruf die Fehlermeldung SSL Bibliotheken konnten nicht geladen werden.
Es klappt auch nicht, wenn ich den Autruf über CMD.exe /C + Signtool... aufruft.

Exakt der gleiche Aufruf "per Hand" aus einer Eingabeaufforderung CMD (nicht powershell) funktioniert problemlos.

Hat jemand eine Idee?

Grüsse Mavarik

[himitsu]

geht es denn manuell im CMD/Terminal?



32 / 64 Bit ... falsche SSL-DLLs?

WinSxS ... falsche/fehlende Version der SSL-DLLs?

falsche/fehlende DLL-Suchpfade

Beim ShellExecute/ShellExecuteEx kann man auch das Arbeitsverzeichnis angeben,
oder vorher im Programm das Arbeitsverzeichnis setzen.

...



Was sagt der ProzessMonitor?
welche DLLs werden gesucht, aber nicht gefunden
usw.

[Mavarik]

Zitat von himitsu:

geht es denn manuell im CMD/Terminal?

Zitat von Mavarik:

Exakt der gleiche Aufruf "per Hand" aus einer Eingabeaufforderung CMD (nicht powershell) funktioniert problemlos.

Zitat von himitsu:

32 / 64 Bit ... falsche SSL-DLLs?

WinSxS ... falsche/fehlende Version der SSL-DLLs?

falsche/fehlende DLL-Suchpfade

s.o.

Zitat von himitsu:

Was sagt der ProzessMonitor?
welche DLLs werden gesucht, aber nicht gefunden
usw.

Gute Frage - der Aufruf dauert unter einer halben sekunde so schnell sehe ich das nicht - oder verstehe ich die Frage nicht?

Grüsse Mavarik

PS.: Das Ganze läuft auf einem Server also auch nicht ganz so einfach zu debuggen... (Lokal geht es natürlich auch)

[shebang]

Zitat von Mavarik:

Gute Frage - der Aufruf dauert unter einer halben sekunde so schnell sehe ich das nicht - oder verstehe ich die Frage nicht?

himitsu meint mit dem Process Monitor zu schauen, wo genau welche DLLs gesucht und gefunden werden.

[himitsu]

ProcessExplorer = LiveAnsicht
ProcessMonitor = Logging



Start aus Explorer/CMD
ungleich
Start aus Delphi-IDE (mit oder ohne debugger bei Win32 mit InlineDebugger)
ungleich
Debuggen aus DelphiIDE für Win64, da externer Debugger

da kann sich so Einiges unterscheiden
* 32 oder 64 Bit
* mit oder ohne Virtualsierung/Redirection (z.B. in Win32 sind standardmäßig einige Pfade umgebogen, wie System32 auf SysWOW64)
* aktuelles Arbeitsverzeichnis
* eventuell zusätzlich gesetzte LibrarySearchPaths
* Umgebungsvariablen
* anderer UserAccount/Rights, mit oder ohne Evaluation
* ...

z.B. Explorer hat Delphi gestartet, das startete den RemoteDebugger, der Debugger startete das Programm und überall kann sich was verändert haben

[Kas Ob.]

I doubt that Process Explorer or Process Monitor will help at all.

The fact that the command is running fine when typed by user (direct input) in the console (CMD), means some sort of isolation had taken place.

So it is either some policy and/or the user isolation is in effect.

OP failed to mentioned what type of application is using, standalone or Windows service ?
OP didn't share or screenshot the exact error message !

So it is more guessing than real investigation.

One thing though might help :
Run Process Explorer as Administrator, and get the User running that application from the Image tab, see if there is something wrong.
Also from Process Explorer, compare the Security tab of your application with the CMD (cmd.exe), see what is different.

After these suggestion, we might have better picture, and someone might help you solving this.

[Kas Ob.]

One more thing, very important one :


Are you handling the return value of ShellExecuteEx ?

Handle that and get the last error, as documented in https://learn.microsoft.com/en-us/wi...hellexecuteexw

[jaenicke]

Zitat von Kas Ob.:

I doubt that Process Explorer or Process Monitor will help at all.

On the contrary - the Process Monitor is the ideal tool for this because it makes it very easy to see where and which DLLs are being searched for.

[Kas Ob.]

Zitat von jaenicke:

Zitat von Kas Ob.:

I doubt that Process Explorer or Process Monitor will help at all.

On the contrary - the Process Monitor is the ideal tool for this because it makes it very easy to see where and which DLLs are being searched for.

Not sure about this case, because we can't trust the error message (which still not supplied here), and ShellExecuteEx is COM meaning there are few things and layers are there between the call and API itself, from security/privileges of the COM object(s) involved and needed for ShellExecuteEx/ShellExecute itself to something might be silly like the lack of CoInitializeEx being called.

For Process Monitor to be helpful here, a direct failure of File or Registry Handling API's should be reported/logged, but with COM/DCOM involved this is not the case, COM will not report missing DLL but missing/unknown/unregistered classes with CLSID names, yet if the object file is deleted then Process Monitor might show that, but again this is not the case as that command is working with direct input, and that what i meant, too many layers to fail.

Even when SignTool doesn't need COM, it will be initialized within the COM object environment, privileges and paths limitation that called it, unlike the streamlined security and privileges for direct loading/calling DLL functions and creating process, COM/DCOM can and might override the caller, they have their own.

[Mavarik]

Zitat von Kas Ob.:

Not sure about this case, because we can't trust the error message (which still not supplied here)

Thanx for your Ideas - bzw...

...die Fehlermeldung "SSL Bibliotheken konnten nicht geladen werden".

Is the error message.

BTW. It works anyway