LoadLibrary() - 998 "ERROR_NOACCESS"
Author
Let me start off by saying I had one DLL loading in just fine. But when I go to load a second DLL it always errors out with a 998 "ERROR_NOACCESS" error.
In my project the DLLs basically contain the code needed to run an AI. Another application I built allows you to write simple code and then behind the scenes it compiles the source and makes it available to the "game".
Basically I'm able to load one AI (DLL) in and watch it do its thing. The next time I send it a command to load a new AI (Separately and for a different entity) it fails. I'm using new variables for the whole process so it shouldn't be stepping on other modules.
Each DLL looks pretty much the same since they are all built in basically the same way. (the DLL just consists of a bunch of structs and one function). I was thinking that perhaps the DLL have something in common that make it share part of the same memory in someway but I have no idea.
I wish I could show you the DLL source, but it's not on this machine.
If you have any ideas, thanks in advance!
-Michael
PRB: LoadLibrary API Fails with 998 (ERROR_NOACCESS) Error
Quote:
...
if the operating system loader encounters an access violation (exception C0000005) while mapping the specified DLL file image or executing the startup code, the loader will set the last error to 998 (ERROR_NOACCESS) and the LoadLibrary() function will fail with a return value of NULL.
...
When an access violation occurs anywhere in the startup code, the exception dispatcher detects whether the process that encountered this exception is being debugged. If so, this first chance exception is sent to the debugger.
To troubleshoot the LoadLibrary() failure, run the application under a debugger and enable first chance exception handling for the C0000005 Access Violation exception. If an access violation occurs when the LoadLibrary() function is called, the application will break into the debugger. The debugger's call stack can then be used to trace where the exception occurred. The stack trace should help you narrow down the actual problem related to the exception being encountered.
...
Author
Thanks for the response, but that's basically the first thing you see in Google when you type in the error code.
When I found it myself I didn't really feel it was helpful.
Then again, my DLLs are compiled in gcc without debugging.
I'm not so sure that MSVS can use any of the debugging info even if I included it.
The DLLs need to be compiled in gcc because it's free, and I can't include a MSVS compiler to be distributed with my system.
When I found it myself I didn't really feel it was helpful.
Then again, my DLLs are compiled in gcc without debugging.
I'm not so sure that MSVS can use any of the debugging info even if I included it.
The DLLs need to be compiled in gcc because it's free, and I can't include a MSVS compiler to be distributed with my system.
Quote:Original post by EnlightenWell, you can add a few OutputDebugString() calls, and catch them with DebugView. You know that the error is coming from DllMain(), or a global class constructor or similar.
When I found it myself I didn't really feel it was helpful.
Then again, my DLLs are compiled in gcc without debugging.
I'm not so sure that MSVS can use any of the debugging info even if I included it.
Quote:Original post by EnlightenVisual Studio 2008 Express is also free (Although AFAIK you can't distribute it yourself)
The DLLs need to be compiled in gcc because it's free, and I can't include a MSVS compiler to be distributed with my system.
Quote:Original post by Enlighten
Thanks for the response, but that's basically the first thing you see in Google when you type in the error code.
When I found it myself I didn't really feel it was helpful.
Then again, my DLLs are compiled in gcc without debugging.
I'm not so sure that MSVS can use any of the debugging info even if I included it.
The DLLs need to be compiled in gcc because it's free, and I can't include a MSVS compiler to be distributed with my system.
The info tells me that you should try looking for an access violation, specifically one that occurs during the "mapping the specified DLL file image or executing the startup code". It's possible to debug without debugging info, it just takes more work. Microsoft's debugger is not the only debugger.
If you can load each DLL separately (i.e., load one, unload, load second), but not both at the same time, it's likely they're stepping on each others toes somehow. Kinda obvious when you state it explicitly, and you've already mentioned you know this, but worth re-iterating.
Remember, it doesn't have to just be a memory location they could be clashing over - any resource would do; a file, a port number allocation, etc.
Remember, it doesn't have to just be a memory location they could be clashing over - any resource would do; a file, a port number allocation, etc.
Author
I'm having a hard time building debugging info into the DLL... Well not that so much, but visual studio doesn't see it or something.
Anyway, here is the code for the DLL. I'm not familiar with the intimate details of DLLs so I'm not sure if including all these structs for every DLL is the problem. (If it is, I don't know how to fix it). Does each dll basically keep the structs to themselves? or if I load two DLLs with the same struct in each will it die?
What do you think?
Complete source i'm using to make the DLLs:
http://pastebin.com/f237fbafc
Anyway, here is the code for the DLL. I'm not familiar with the intimate details of DLLs so I'm not sure if including all these structs for every DLL is the problem. (If it is, I don't know how to fix it). Does each dll basically keep the structs to themselves? or if I load two DLLs with the same struct in each will it die?
What do you think?
Complete source i'm using to make the DLLs:
http://pastebin.com/f237fbafc
I can't see anything that would cause that code to fail to be loaded into another process as a DLL.
When you were running in a debugger over your LoadLibrary call, did you enable first-chance exception handling for 0xc0000005 beforehand? The page LessBread linked explicitly mentions to do that;
You do this in the Debug -> Exceptions menu in MSVS.
Perhaps you could post the code that calls LoadLibrary to load the DLLs.
Also, have you tried building the DLLs in MSVS instead of gcc, just to see what happens?
When you were running in a debugger over your LoadLibrary call, did you enable first-chance exception handling for 0xc0000005 beforehand? The page LessBread linked explicitly mentions to do that;
Quote:To troubleshoot the LoadLibrary() failure, run the application under a debugger and enable first chance exception handling for the C0000005 Access Violation exception.
You do this in the Debug -> Exceptions menu in MSVS.
Perhaps you could post the code that calls LoadLibrary to load the DLLs.
Also, have you tried building the DLLs in MSVS instead of gcc, just to see what happens?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
