LoadLibraryW returns nullptr, and GetLastError() returns 3221225619

Question

To describe the problems I've been having would take too long, but the the problem at the sharp end is:

1. LoadLibraryW fails (returns nullptr) when given a valid path.

2. Process Monitor records no suspicious failures, or indeed anything different from when it succeeds in loading the dll (which it can in another context).

3. The dll has no non-system dependencies.

4. ...and worst of all, the Windows error code returned by GetLastError is 3221225619.

Assuming that 3221225619 is not a valid error code, what could be going so wrong that Windows doesn't even have an error code for it?

EDIT:

I think some people have wanted more details on the failure itself:

• It does not appear to be the input - it is identical in the working and failing version, and LoadLibraryW has successfully declared "file does not exist" when the input string has been mutilated. The current input has it hard-coded in, leaving little room for error.
• The dll is compiled in Release and the calling code in Debug. I've been doing this for 18 months without a problem, but you never know.
• The Process Monitor package reports about 30 internal operations running within LoadLibraryW, including CreateFile, LoadImage, RegOpenKey. These are identical for the working call and the failing call, down to the sizes of files and the memory locations.
• There's no obvious memory corruption in the C++ object calling it, and as I said, Process Monitor gives the same Base Image address in both cases.
• The failure's 100% consistent - same time, same place every time.

Answer 1

Sorry, this is not exactly an answer, but the issue has been resolved.

To start with, I've just noticed a similar question here: C++ Loadlibrary() error 3765269347. I think this one gives more details, and is worth a look if you're in a similar position to what I was.

My thanks to @WhozCraig, @DanielDaranas and everybody else who made helpful comments. For other people reading this, there is a good article on HRESULT which expands on their points on Wikipedia: http://en.wikipedia.org/wiki/HRESULT.

In my case, the problem has gone away as mysteriously as it arose. I have created a C++ class to call the dll on a regular basis. My original effort loaded the dll immediately before the first call, and cached it in memory. This is the same in principle to how it's worked for over a year. This resulted in the mysterious error above.

I have refactored it to load the dll during construction, but to only extract the function from it at run time. This apparently works, and is probably a better way of doing it (loading the dll during construction, freeing it during destruction). As there is very little going on between the construction and the first call to the dll, I cannot see why one method should produce a OS error, and the other does not.