I had a very interesting bug to solve the other day. We have a .Net application which uses a third party dll (CoreLab) as our ADO connection to an Oracle database. In this case, we had only one person who could not connect and got the following exception:

"Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

I couldn't track down the exact cause of this exception. Everyone else worked. He could connect to a different Oracle instance on another machne. He just couldn't connect to his local instance. Even more odd, I could connect from my box to his instance.

Our application is rather large and complex so I quickly wrote a test app I could deploy easily to his box. CoreLab kinda sucks in my opinion and we've had trouble with them before so I added method to connect using CoreLab ADO and just to cover my bases I also added a method to connect using MS ADO.

Both methods succeeded.

I then copied and pasted the connection code from from our application into my test app. I commented out references to what I thought was "unnecessary" code which referenced external DLLs which didn't appear to be applicable (logging to be specific). This was done just to get the application to build easily without having to complicate matters with references to other dll's.

Both Methods succeeded.

I removed the comments to the "unnecessary" code and added references to the external DLLs. Essentially, this was a reference to a utility project with logging code. The logging code made a reference to a security dll.

The test application failed. Aha!

I commented out the single line of code for logging. The test application still failed.

Another developer had just recently added the Security.dll and so I thought this might be a reasonable point to place my suspicions. I also remember wishing he hadn't named the project "Security". What security? Who's security? I always add an application or company name beforehand. For example, "AjaxSecurity.dll". 

At this point however, there isn't any code path into the referenced external DLLs.

I removed all code and reference to Security.dll and built the project again. The application succeeded.

This time, I created an empty project called Security.dll without any code: no properties, fields, methods or events. Just a big bag of nothing.

I then added a reference to the empty Security.dll project.

This time the method failed!

What I found was if I renamed or deleted the empty Security.dll file from the folder, the method succeeded. If I pasted the file back in, the method failed.

In summary, the application did not REQUIRE the Security.dll to run and did not have any code path INTO the Security.dll file, however just the PRESENCE of the Security.dll file caused the connection method to fail.

It's my guess that the ADO.Net code to make a connection calls into .Net Security code. The .Net Framework initially looks for the Security.dll in the current folder. If it can't find it, then it looks in the GAC. Since the framework found a DLL named Security, it thinks this is the code it needs and fails, but the code it really needs is in the GAC.

As indicated above, all projects should be prefixed with a company name or some other identifier.