Dear CPians: Help me out by voting for this
-
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
-
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 had a slightly more general approach to a similar problem in this Message http://www.codeproject.com/Messages/3168696/Throw-it-like-you-mean-it.aspx[^], the message thread went a bit way ward (sorry for that) but in general I think MS can make an effort to add more detail to exceptions in general. I agree it will not be easy like you said, but it would increase quality significantly of their and our products. I think MS did a great job when they designed the Exception model for .Net, but it might be time for them to spend some more effort to enhance it some more...
____________________________________________________________ Be brave little warrior, be VERY brave
-
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, Vote++; 12:50PM (GMT +7) best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
-
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
Voted it up. Well, due to these arbitrary difficulties in VC++/.NET, I over the years switched to PHP/MySQL after completing my span of being a workplace hero in Windows environment for half a decade. And I must say, I am much more happy and productive in PHP/MySQL environment :laugh: but seriously miss the challenging and real development of VC++ days. :(( - Pragmatic Programmer
-
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.
Nice one Rama!
Daniel Vaughan Blog: DanielVaughan.Orpius.com
Company: Outcoder -
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.
Probably even easier still to go to the beach with your family while MS does their danged jobs. ;P
-
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
+1
-
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.
:thumbsup: very useful and thanks also to the gentleman suggesting an event handler approach; may code be forever cleaner and more readable with error handling out of the way :-D
-
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 did my part.
PlutoX
-
Hi Judah, Vote++; 12:50PM (GMT +7) best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
Thanks, Bill!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
+1
Thanks!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
I did my part.
PlutoX
Thank you!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Voted it up. Well, due to these arbitrary difficulties in VC++/.NET, I over the years switched to PHP/MySQL after completing my span of being a workplace hero in Windows environment for half a decade. And I must say, I am much more happy and productive in PHP/MySQL environment :laugh: but seriously miss the challenging and real development of VC++ days. :(( - Pragmatic Programmer
Thanks, Shamit!
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
Added my vote ...