0

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.
Mike Sadler
  • 1,750
  • 1
  • 20
  • 37
  • what do you have on DllMain of the library being loaded? – Jorge Ferreira Nov 07 '13 at 11:21
  • I'm just calling it from an executable directly. – Mike Sadler Nov 07 '13 at 11:22
  • have you coded the dll in question? – Jorge Ferreira Nov 07 '13 at 11:23
  • Have you validated the DLL is the correct architecture? I.e. you're not trying to load a 32bit DLL in a 64bit process, or vice-versa, are you? – WhozCraig Nov 07 '13 at 11:24
  • I could load the dll fine before making a minor architecture change, and I can still load it in the same session using the old architecture. The architecture change in question involves minor tweaks to the timing of when char* strings are changed to wchar_t* strings and vice versa. I've tried all sorts of things to isolate the problem, and when it comes down to it, LoadLibraryW *does* seem to find the dll correctly. – Mike Sadler Nov 07 '13 at 11:29
  • The only thing left that I can think of is some subtle memory corruption, but I can't see any, and Process Monitor doesn't seem to show any obvious problems (it shows Windows finding the dll, loading into a valid memory address, etc). – Mike Sadler Nov 07 '13 at 11:31
  • 1
    Btw, **ERROR_IS_JOIN_PATH** is your specific error if I dissected it correctly, and the crux of it is: "Not enough resources are available to process this command". Both severity bits are lit, indicating an outright error, and the facility code is FACILITY_NULL, indicating a base OS error. Not that this helps you much, but at least you know now. (though I could have sworn a 0x93 with 0xC000 in the top word was an invalid kernel handle, but its been so long I'm probably wrong). – WhozCraig Nov 07 '13 at 11:37
  • 1
    @WhozCraig Now how did you manage to get that? All I've managed to find is EXCEPTION_FLT_UNDERFLOW, which doesn't make much sense at the point it's trying to *load* the dll (running, maybe). Would you be able to phrase this as a full answer? I didn't expect anyone to be able to solve my problem from the information I've provided - I just wanted to know how to interpret the error code... – Mike Sadler Nov 07 '13 at 11:42
  • Its not actually an *answer*, all I did was hunt an error code. I just wish I could help you understand why your DLL Load fails with that condition. *That* would be an answer. I've seen stranger things, usually due to junk people shouldn't be doing in DLLMain and such. – WhozCraig Nov 07 '13 at 11:47
  • @WhozCraig don't be so modest - my question was actually "what is the error code" - I haven't had any luck finding it on the web. I take it from your original comment that the error code can be broken down into binary bits? In which case, what resource is there out there to make sense of it? – Mike Sadler Nov 07 '13 at 13:44
  • 3221225619 is 0xC0000093, i.e. `C000 0093 hex`. – Daniel Daranas Nov 07 '13 at 14:40
  • 1
    @MikeSadler If it is a standard HRESULT format (and it would seem reasonable), the top two bits are the severity code (both set is bad, btw), then a couple bits for other stuff, then a 12 bit facility code, and finally a 16-bit error value. With all that, go crack open `winerror.h` and start searching. It is *possible* it is a invalid kernel handle error, but it would be an odd way of reporting it. – WhozCraig Nov 07 '13 at 16:11

1 Answers1

0

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.

Community
  • 1
  • 1
Mike Sadler
  • 1,750
  • 1
  • 20
  • 37