This has happened twice on separate machines, both using Win XP, SP2, VS 2005 Pro. Both times it seems to occur at the same place in my application (I'm not really sure about this since it has been some time since the first time), AccessViolationException when I want a MsgBox to pop up in my GUI.
Well, obviously something in my code is bad, even though it has happened only two times of about 1000...
But the real severe problem arises afterwards. I cannot run the application, not in debug mode, not the exe file, not ANY previous versions of my application! I can still build it, but NEVER run it. In debug mode exceptions are thrown at startup, but not the same every time. Typically an TypeInitializationException or an AccessViolationExpception is thrown. It generally seems that NOTHING works. And this is code I have runned successfully a 1000 times prior to the crash. When I run the exe file I get the message "Application has generated an exception that could not be handled."
The first time this happened I reinstalled .NET 2.0, VS 2005, nothing worked. Note that the same code runs on other machines. Eventually, I did not know what to do so I reformatted the disk, and reinstalled XP and everything. Afterwards it worked again. I thought that this was a "one-timer", but now, the same thing has happened again on another computer!
This is a severe security problem! I mean, my code is probably unsafe but the damage is not by far motivated!
Hopefully someone knows what this is about and can help me. My application is supposed to be commersial software...
Thanks
Magnus
Severe security problem in .NET found.
roychoo
Thanks for your reply. After some digging I know the origin of the crash, but I don't really understand the consequences.
A custom made dll that I use (wrapped in a .NET class) in some way malfunctions when it reads a text file and the contents of this file is errounus. I have not developed this dll so I don't really know what happens. But I know that it has severe consequences for my application. Subsequent code (not related to the dll) throws exceptions about various things (not the same place every time), all problems seem memory related. So the dll messes things up in general! That the code in the first crash was a MessageBox.Show() call, I consider a coincident.
Can this problem be handled in some way, from .NET Probably not. Unfortunately I can't change the dll...
Best regards
Magnus
Ola Hallengren
You mentioned that this custom DLL is wrapped in a .NET class. Do you have control over the wrapper class If so you could try wrapping the calls to the DLL in try-catch blocks. This would prevent any exceptions from bringing down your app directly but it still doesn't resolve the bad data. Depending on the actual problem it is causing you might not be able to do anything. For example if it is arbitrarily accessing some memory address and overwriting it then there is not much you can do beyond try to catch any exceptions that eventually get thrown. The Dll itself should reside in its own memory range so the problem would be if it arbitrarily references memory outside its memory range (and which happens to match the memory being used by .NET). Ultimately there is nothing you can do to somehow recover from that situation as you don't have control over the dll. Your best option is to go back to the original developer and have them fix the dll. An alternative is to find another mechanism to use and remove the dll altogether.
Since it is a dll if it wants to overwrite memory then there is really nothing you can do about it directly. The only way to somehow guarantee that your main app doesn't go down no matter what the dll does would be to push the dll to another process (perhaps a COM server). However creating a COM server just to work around a bug is probably not the best approach. You still can't prevent the process from crashing on the COM server side so you'll still end up having to use try-catch blocks everywhere. I stand by the original recommendation of going back to the developer and getting them to fix the issue or replace the custom dll with a better behaving version.
Michael Taylor - 10/18/06
kageg
Can you provide some more information like whether you are running multiple threads Is it a full-trust application Are you running it local or from the network Is it a service or something Can you post the code surrounding the message box and what the context of the app is at the time
Michael Taylor - 10/18/06