WinVerifyTrust returns 0x80092003 - CRYPT_E_FILE_ERROR

Question

I am working on C# .net 3.5 and running on 64 bit platform.

I have a 32 bit dll that I need to dynamically load. The dll is located under "C:\Program files\ApplicationToLoad\Application.dll"

because the dll is 32 bit I have to compile my application also to 32 bit.

Before loading the dll I check if the dll is signed using WinVerifyTrust, but I get an error 0x80092003 = CRYPT_E_FILE_ERROR = An error occurred while reading or writing to the file.

I guessed that happens becuase I am compiled to 32 bit and trying to check a dll that is under Program Files and not Program Files x86. So I followed the answer at Verify digital signature within system32/drivers folder and tried to disable the FS redirection but it didn't help.

I am quite sure that the problem is releated somehow to the redirection, because I

created a copy of ApplicationToLoad folder under "program Files (x86)' - WinVerifyTrust returned status OK
Compiled my application to 64 bit - WinVerifyTrust returned status OK

UPDATE:

This is the code the disables the redirection:

 IntPtr ptr = new IntPtr();
  Wow64DisableWow64FsRedirection(ref ptr);
  var lStatus = WinVerifyTrust(
                    IntPtr.Zero,
                    pGuid,
                    pData);

 Wow64RevertWow64FsRedirection(ptr);

pinvoke declarations:

 [DllImport("kernel32.dll", SetLastError = true)]
            public static extern bool Wow64DisableWow64FsRedirection(ref IntPtr ptr);
            [DllImport("kernel32.dll", SetLastError = true)]
            public static extern bool Wow64RevertWow64FsRedirection(IntPtr ptr);

File system redirection sounds very likely to be the troublemaker. Why is this DLL stored in the wrong folder? Post the code that disables redirection. — Hans Passant, Oct 10 '12 at 13:21
The dll is not mine :( I don't know why they did such a stupid thing... — user844541, Oct 10 '12 at 13:51

score 0 · Accepted Answer · answered Oct 10 '12 at 14:02

I figured it out - the problem was that there was an extra space in the file path. and the code of getting the file path in 32 bit and 64 bit was different that's why it didn't reproduce when compiled to 64 bit. so it got nothing to do with the redirection...

WinVerifyTrust returns 0x80092003 - CRYPT_E_FILE_ERROR

1 Answers1