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.