Dear CPians: Help me out by voting for this
-
Thanks, Mustafa!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
No worries :) Besides, I'll get a benefit out of this too! (assuming they actually help out)
If the post was helpful, please vote, eh! Current activities: Book: Devils by Fyodor Dostoyevsky Project: Hospital Automation, final stage Learning: Image analysis, LINQ Now and forever, defiant to the end. What is Multiple Sclerosis[^]?
-
Dear CPians, Have you ever written a .NET desktop or web application that talks to a SQL database? Uses WinForms controls? Talks to COM objects? Talks to Win32 via P/Invoke? If so, you may have run into the dreaded AccessViolationException: Some managed code called into unmanaged code, and memory was corrupted. Maybe you passed a bad argument to the unmanaged function. Maybe there's a bug in the managed-to-native interop. Whatever the case, when it happens, all you get is an unhelpful message and a useless stack trace, making it near-impossible to debug. Please vote up this MSConnect case[^] so Microsoft gives us more information when these errors occur. If MS gives us more information, devs can fix crashing .NET apps, users will be happier, and the world will be a better place. Thank you.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
Hi Judah, You have my vote on that.
It is a crappy thing, but it's life -^ Carlo Pallini
-
Hi Judah, You have my vote on that.
It is a crappy thing, but it's life -^ Carlo Pallini
Thanks, Rajesh!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
The exception almost never occurs on our dev machines, but instead on end user machines where no debugger is installed. The exception reported to us is near useless:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Stack Trace: at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg) at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData) at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.Run(Form mainForm) at MyProgram.Main
Is there some secret way to debug such crashing errors? If not, I'm asking for more information in the error message to help us track down the error.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
Yes there is. Do you want me to post here or as an article? Are programming ansers allowed in Lounge?
-
Yes there is. Do you want me to post here or as an article? Are programming ansers allowed in Lounge?
Hahah. Awesome. Rama to the Rescue. Doesn't matter to me whether it's an article or an lounge answer. Please show us your magic tricks, uncle Rama. :) On second thought, an article would probably be better. Share the wealth of knowledge, get more publicity.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Dear CPians, Have you ever written a .NET desktop or web application that talks to a SQL database? Uses WinForms controls? Talks to COM objects? Talks to Win32 via P/Invoke? If so, you may have run into the dreaded AccessViolationException: Some managed code called into unmanaged code, and memory was corrupted. Maybe you passed a bad argument to the unmanaged function. Maybe there's a bug in the managed-to-native interop. Whatever the case, when it happens, all you get is an unhelpful message and a useless stack trace, making it near-impossible to debug. Please vote up this MSConnect case[^] so Microsoft gives us more information when these errors occur. If MS gives us more information, devs can fix crashing .NET apps, users will be happier, and the world will be a better place. Thank you.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
:confused:
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Uh... reply to the wrong post! Oh how will you get over the shame!!! ;p
If the post was helpful, please vote, eh! Current activities: Book: Devils by Fyodor Dostoyevsky Project: Hospital Automation, final stage Learning: Image analysis, LINQ Now and forever, defiant to the end. What is Multiple Sclerosis[^]?
-
Hahah. Awesome. Rama to the Rescue. Doesn't matter to me whether it's an article or an lounge answer. Please show us your magic tricks, uncle Rama. :) On second thought, an article would probably be better. Share the wealth of knowledge, get more publicity.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
I wrote a test application to validate my theory and it works. Of course, it can be improved a lot. The idea is to get the dll name and the address at which the access violation occured. I wrote a C++ dll called Crasher with a method that causes access violation:
extern "C" _declspec(dllexport) int _stdcall CrashMyApp()
{
char* sz = 0;
*sz = 0;return -1;}
Now I call this from a managed assemvbly and catch access violation and get more information:
static void Main(string[] args)
{
try
{
CrashMyApp();
}
catch (AccessViolationException)
{
IntPtr ex = Marshal.GetExceptionPointers();EXCEPTION\_POINTERS pointers = (EXCEPTION\_POINTERS)Marshal.PtrToStructure(ex, typeof(EXCEPTION\_POINTERS)); EXCEPTION\_RECORD rec = (EXCEPTION\_RECORD)Marshal.PtrToStructure(pointers.ExceptionRecord, typeof(EXCEPTION\_RECORD)); Console.WriteLine("Exception in {0} at {1:x8}", DllNameFromAddress(rec.ExceptionAddress), rec.ExceptionAddress.ToInt32()); // Usually you wil re-throw may be wrapping in some other exception // Bad idea to catch AccessViolationException and do nothing }}
All the utility methods are in the project download link at the bottom of the post. So the output is like this:
Exception in C:\Users\ramakrishna\Documents\Visual Studio 2008\Projects\UnmanagedDebugging\Debug\Crasher.dll at 77b71328
Download link here: Crasher.zip (8.5 KB) Of course, you can build a lot fancy stuff like load the symbols, generate mini-dumps etc.
-
Yes there is. Do you want me to post here or as an article? Are programming ansers allowed in Lounge?
-
I wrote a test application to validate my theory and it works. Of course, it can be improved a lot. The idea is to get the dll name and the address at which the access violation occured. I wrote a C++ dll called Crasher with a method that causes access violation:
extern "C" _declspec(dllexport) int _stdcall CrashMyApp()
{
char* sz = 0;
*sz = 0;return -1;}
Now I call this from a managed assemvbly and catch access violation and get more information:
static void Main(string[] args)
{
try
{
CrashMyApp();
}
catch (AccessViolationException)
{
IntPtr ex = Marshal.GetExceptionPointers();EXCEPTION\_POINTERS pointers = (EXCEPTION\_POINTERS)Marshal.PtrToStructure(ex, typeof(EXCEPTION\_POINTERS)); EXCEPTION\_RECORD rec = (EXCEPTION\_RECORD)Marshal.PtrToStructure(pointers.ExceptionRecord, typeof(EXCEPTION\_RECORD)); Console.WriteLine("Exception in {0} at {1:x8}", DllNameFromAddress(rec.ExceptionAddress), rec.ExceptionAddress.ToInt32()); // Usually you wil re-throw may be wrapping in some other exception // Bad idea to catch AccessViolationException and do nothing }}
All the utility methods are in the project download link at the bottom of the post. So the output is like this:
Exception in C:\Users\ramakrishna\Documents\Visual Studio 2008\Projects\UnmanagedDebugging\Debug\Crasher.dll at 77b71328
Download link here: Crasher.zip (8.5 KB) Of course, you can build a lot fancy stuff like load the symbols, generate mini-dumps etc.
Rama, you're a rockstar. I'll give this a try and see if we can implement it in our app. That would at least give us a clue as to which dll failed. Thanks a million!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Uh... reply to the wrong post! Oh how will you get over the shame!!! ;p
If the post was helpful, please vote, eh! Current activities: Book: Devils by Fyodor Dostoyevsky Project: Hospital Automation, final stage Learning: Image analysis, LINQ Now and forever, defiant to the end. What is Multiple Sclerosis[^]?
-
Rama, you're a rockstar. I'll give this a try and see if we can implement it in our app. That would at least give us a clue as to which dll failed. Thanks a million!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
Probably it might be easier to put the code in an event handler for Application.ThreadException. That way you don't have to add individual try-catch blocks.
-
IF you do this as an article, please post something to let us know. I don't check the article feed often enough to spot a lot of new stuff.
The latest nation. Procrastination.
I don't think I will be able to post as an article in finite time. So I have posted a reply to Judah with code.
-
Probably it might be easier to put the code in an event handler for Application.ThreadException. That way you don't have to add individual try-catch blocks.
Yep, that's what I had in mind, too. Thanks again!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Dear CPians, Have you ever written a .NET desktop or web application that talks to a SQL database? Uses WinForms controls? Talks to COM objects? Talks to Win32 via P/Invoke? If so, you may have run into the dreaded AccessViolationException: Some managed code called into unmanaged code, and memory was corrupted. Maybe you passed a bad argument to the unmanaged function. Maybe there's a bug in the managed-to-native interop. Whatever the case, when it happens, all you get is an unhelpful message and a useless stack trace, making it near-impossible to debug. Please vote up this MSConnect case[^] so Microsoft gives us more information when these errors occur. If MS gives us more information, devs can fix crashing .NET apps, users will be happier, and the world will be a better place. Thank you.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
I usually ran into this type of errors when using unmanaged COM object within managed code. Usually the memory error emerges upon closing the main application. In my case I found out that the problem originates in the fact that the GC doesn’t works well with global unmanaged objects. For some strange/for me/ reason the GC doesn’t collect these objects. The solution was simple: in any class containing a global unmanaged objects I implement Dispose() and put inside:
System.Runtime.InteropServices.Marshal.ReleaseComObject((object)YourGlobalObjectHere);
Hope that would helps.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
I usually ran into this type of errors when using unmanaged COM object within managed code. Usually the memory error emerges upon closing the main application. In my case I found out that the problem originates in the fact that the GC doesn’t works well with global unmanaged objects. For some strange/for me/ reason the GC doesn’t collect these objects. The solution was simple: in any class containing a global unmanaged objects I implement Dispose() and put inside:
System.Runtime.InteropServices.Marshal.ReleaseComObject((object)YourGlobalObjectHere);
Hope that would helps.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
Thanks for the tips. For us, this error occurs during regular runtime use of the app. That's a problem. Sometimes on close, but other times just out of the blue. Rama has some tips (see above) that will help us track down the native dll and native method in which the memory was corrupted. From there, we should be able to further diagnose, and hopefully fix, the issue.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
I wrote a test application to validate my theory and it works. Of course, it can be improved a lot. The idea is to get the dll name and the address at which the access violation occured. I wrote a C++ dll called Crasher with a method that causes access violation:
extern "C" _declspec(dllexport) int _stdcall CrashMyApp()
{
char* sz = 0;
*sz = 0;return -1;}
Now I call this from a managed assemvbly and catch access violation and get more information:
static void Main(string[] args)
{
try
{
CrashMyApp();
}
catch (AccessViolationException)
{
IntPtr ex = Marshal.GetExceptionPointers();EXCEPTION\_POINTERS pointers = (EXCEPTION\_POINTERS)Marshal.PtrToStructure(ex, typeof(EXCEPTION\_POINTERS)); EXCEPTION\_RECORD rec = (EXCEPTION\_RECORD)Marshal.PtrToStructure(pointers.ExceptionRecord, typeof(EXCEPTION\_RECORD)); Console.WriteLine("Exception in {0} at {1:x8}", DllNameFromAddress(rec.ExceptionAddress), rec.ExceptionAddress.ToInt32()); // Usually you wil re-throw may be wrapping in some other exception // Bad idea to catch AccessViolationException and do nothing }}
All the utility methods are in the project download link at the bottom of the post. So the output is like this:
Exception in C:\Users\ramakrishna\Documents\Visual Studio 2008\Projects\UnmanagedDebugging\Debug\Crasher.dll at 77b71328
Download link here: Crasher.zip (8.5 KB) Of course, you can build a lot fancy stuff like load the symbols, generate mini-dumps etc.
-
Thanks for the tips. For us, this error occurs during regular runtime use of the app. That's a problem. Sometimes on close, but other times just out of the blue. Rama has some tips (see above) that will help us track down the native dll and native method in which the memory was corrupted. From there, we should be able to further diagnose, and hopefully fix, the issue.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
Don’t forget to enable the unmanaged code debugging from the main project options. A few weeks ago I lost two hours investigating why I don’t hit the breakpoints in the DLL code. :-O
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
Don’t forget to enable the unmanaged code debugging from the main project options. A few weeks ago I lost two hours investigating why I don’t hit the breakpoints in the DLL code. :-O
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
Unfortunately, these errors most often occur on end-users machines, where no debugger exists. Hence the need for additional info when these errors occur.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango