[VS C++ 7.0 - MASM32 9.0 assembler] I have a strange problem, that has taken me at least 3 hours to finally figure out that it might not be a problem, but strange still? I'm calling an assembly function in a DLL from a Win32 C++ executable. If I debug and/or run the program from the DLL project (by selecting the executable as the command option in the DLL project's properties) the assembly function works fine, and outputs correct. If I run the program without debugging from its own project the function also works fine, and by logging the output, I can see it numerically was successful too. Now, if i debug (F5) the program from its project I get this error: Unhandled exception at 0x100b987a (MyDLL.dll) in MyDLL_Debugger.exe: 0xC0000005: Access violation writing location 0x34f811fc. Since I had a few logic errors in the assembly function, I was originally debugging to fix these, which I apparantly did, but when I started getting this error I just couldn't understand what I had changed or added to cause it. When I finally tried running without debugging I had great surprise in no exception being raised! I've restarted, cleared memory, etc. for any chance of some weird register flag being stuck or something. If this isn't enough information for a general solution, I can post the relevant assembly code (which uses 3DNow! instructions).

I doubt that it's the solution, but comparing the project settings for debug and release may be an option...

You probably still have the bug, it is just hidden in release mode. When in debug mode there are often extra checks to make sure you don't have any bugs. In this case it probably sees that you are overwriting some of your old memory which is still in use and throws an exception. In release mode it just silently replaces the content of the memory and while it may not have an immediate effect it is sure to have serious consequences later.

This has become so bizarre I don't know if it could be a hardware problem now? I got desperate and simply copied a working assembly function the over the buggy one and renamed it back. Lo! Still an exception! Its supposed to be running the exact same code as the well-working function, just with a different naming symbol. So I thought maybe a screwed up symbol definition or prototype was tricking the compiler to thinking I was outputing or inputting different types, but no, I had changed everything to the working function, just with different name.

So I cut the working function code (previously the last function in the assembly module) and pasted it before the buggy one (the second to last). Now they are swapped, the buggy one is fine the good one is buggy. The only thing I changed was the order in which the functions were defined in the assembly module...what could this possibly mean? Could some memory address be corrupted or how could the order of the definition affect which function throws an access violation exception? There are no interdependencies or anything like that at all between the two functions.

Your error is still there.

But now, rather than writing outside of allocated memory, you're happily overwriting allocated memory. This doesn't result in an immediate error, but you are corrupting your data.

This is almost certainly a problem with your code. There is a slight chance of something fishy going on with inclusion of assembly, but that chance is small.

You're simply accessing memory you should be from your assembly function - if that is indeed the cause of the problem. It could be elsewhere.

But now I copy both functions (now the old one back to its original code) into another assembly module and there are no exceptions at all. It seems that anything from that particular area in that one assembly module generates the exception, regardless of actual code?

Could you please specify what you are actually doing in your module?

The modules are just groups of function implimentations for a C++ DLL. They are grouped logically, not with any modular necessity, and all the modules include the same .inc file with prototypes and constants defined in it.

I have had these kind of problems before when working with an old project of mine, it is, like others have said, a coding mishap (quite easy to do, and hard to trace). The way you described it happening the way it does, it makes me believe that internaly your writing over the vtable, or the function code internaly.

Remembering and Covering some general rules of programming MIGHT help a bit

what you NEW your must DELETE, and what you ALLOCATE you must FREE, you cant mix these up at all. It may appear to work at the onset, but can cause major problems later on in the applications cycle.

in addition, this is important when using DLLS. When you allocate memory in a dll, you must deallocate that memory in the DLL. This is quite possiably the problem actualy. Lets say you create a structure on the stack, and pass it to the DLL, and the DLL sets a char* inside of the structure. YOU CANT DELETE THAT OUTSIDE OF THE DLL! If the pointer is to memory owned by the dll, you must pass it back to the dll.