LoadLibrary() - 998 "ERROR_NOACCESS" - GameDev.Net Discussion Forums

Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic

Last Thread Next Thread

LoadLibrary() - 998 "ERROR_NOACCESS"

Enlighten Member since: 11/28/2004 From: Grants Pass, Oregon

Posted - 11/2/2009 3:13:42 PM

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

User Rating: 1006 | Rate This User

Report this Post to a Moderator | Link

LessBread Moderator Member since: 12/19/2001 From: Fresno, CA, United States

Posted - 11/2/2009 3:37:34 PM

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.
...

User Rating: 1903 | Rate This User

Report this Post to a Moderator | Link

Enlighten Member since: 11/28/2004 From: Grants Pass, Oregon

Posted - 11/2/2009 3:56:43 PM

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.

User Rating: 1006 | Rate This User

Report this Post to a Moderator | Link

Evil Steve Moderator Member since: 6/30/2003 From: Glasgow, United Kingdom

Posted - 11/2/2009 4:05:04 PM

Quote:
Original post by Enlighten
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.

Well, 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.

Quote:
Original post by Enlighten
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.

Visual Studio 2008 Express is also free (Although AFAIK you can't distribute it yourself)

Steve Macpherson
DirectX MVP and Programmer, Firebrand Games

User Rating: 2014 | Rate This User

Report this Post to a Moderator | Link

Codeka Member since: 10/19/2008 From: Sydney, Australia

Posted - 11/2/2009 4:56:17 PM

GDB is available on Windows for debugging.

my blog

User Rating: 1645 | Rate This User

Report this Post to a Moderator | Link

LessBread Moderator Member since: 12/19/2001 From: Fresno, CA, United States

Posted - 11/2/2009 4:57:38 PM

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.

User Rating: 1903 | Rate This User

Report this Post to a Moderator | Link

Enlighten Member since: 11/28/2004 From: Grants Pass, Oregon

Posted - 11/2/2009 5:00:23 PM

Awesome, GDB and DebugView, that will give me something to work with.
Thanks!

User Rating: 1006 | Rate This User

Report this Post to a Moderator | Link

mattd Member since: 2/26/2000

Posted - 11/3/2009 2:25:41 AM

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.

User Rating: 1611 | Rate This User

Report this Post to a Moderator | Link

Enlighten Member since: 11/28/2004 From: Grants Pass, Oregon

Posted - 11/3/2009 5:34:29 PM

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

User Rating: 1006 | Rate This User

Report this Post to a Moderator | Link

mattd Member since: 2/26/2000

Posted - 11/4/2009 1:07:00 AM

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;

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?

User Rating: 1611 | Rate This User

Report this Post to a Moderator | Link

All times are ET (US)

Last Thread Next Thread

Forum Rules:

You may not post new threads
You may post replies
You may not edit your posts
You may not use HTML in your posts

Jump To: