Unhandled exception
-
Hi There. How to catch exceptions occurred in DLL. For example main() { try { calling the “A.DLL” (DLL(donot know the source code) is generating unhandled exception, access violation) } catch(...) { //Source Code } } Even if I have catch(...) I am not able to catch the exeption. It says unhandled exeption..... Access violation reading.... How I do catch it in my main program so that I can terminate it properly? Thanks -PanB
-
Hi There. How to catch exceptions occurred in DLL. For example main() { try { calling the “A.DLL” (DLL(donot know the source code) is generating unhandled exception, access violation) } catch(...) { //Source Code } } Even if I have catch(...) I am not able to catch the exeption. It says unhandled exeption..... Access violation reading.... How I do catch it in my main program so that I can terminate it properly? Thanks -PanB
-
-
Thanks Richard. It worked. I really working hard with Google but when was not able to get any solution, then only came for expert advice. Thanks anyway. Keep up the good work.
-
Hi There. How to catch exceptions occurred in DLL. For example main() { try { calling the “A.DLL” (DLL(donot know the source code) is generating unhandled exception, access violation) } catch(...) { //Source Code } } Even if I have catch(...) I am not able to catch the exeption. It says unhandled exeption..... Access violation reading.... How I do catch it in my main program so that I can terminate it properly? Thanks -PanB
In general the best thing to do with an access violation in some DLL you don't have source code for is to crash. It's amateurish to think that catching it solves any problems. If you think about it, it's self evident:
- Something went wrong.
- The unexpected event happened part way though a sequence of steps that probably should have been atomic.
I'll give some specific examples of the kind of problems that could occur:
- You were adding a node to a double-linked list when the access violation occurred. Now you have a node that is only partially linked in. Instead of crashing at the point of insertion you crash down the track when iterating over the list.
- The access violation happens after a call to
EnterCriticalSectionbut before the correspondingLeaveCriticalSection. Instead of crashing at the problem location an entirely different thread now locks up. - The crash was the last of a series of memory accesses of which some of the earlier ones (that didn't cause a crash) corrupted the heap. You'll now crash at some later time when allocating or freeing memory.
You could come up with a million of these examples. In most cases "recovering" from low-level exceptions by catching them turns a bad problem into a worse one. Sometimes crashing is a feature; don't make things worse trying to "fix" things. You may already know all this (you did mention something about terminating correctly), but I thought it best to point out just in case. There's also the fact that moving the manifestation of a problem (a crash) even slightly from the source of the problem makes it many times harder to fix in future.
Steve
-
In general the best thing to do with an access violation in some DLL you don't have source code for is to crash. It's amateurish to think that catching it solves any problems. If you think about it, it's self evident:
- Something went wrong.
- The unexpected event happened part way though a sequence of steps that probably should have been atomic.
I'll give some specific examples of the kind of problems that could occur:
- You were adding a node to a double-linked list when the access violation occurred. Now you have a node that is only partially linked in. Instead of crashing at the point of insertion you crash down the track when iterating over the list.
- The access violation happens after a call to
EnterCriticalSectionbut before the correspondingLeaveCriticalSection. Instead of crashing at the problem location an entirely different thread now locks up. - The crash was the last of a series of memory accesses of which some of the earlier ones (that didn't cause a crash) corrupted the heap. You'll now crash at some later time when allocating or freeing memory.
You could come up with a million of these examples. In most cases "recovering" from low-level exceptions by catching them turns a bad problem into a worse one. Sometimes crashing is a feature; don't make things worse trying to "fix" things. You may already know all this (you did mention something about terminating correctly), but I thought it best to point out just in case. There's also the fact that moving the manifestation of a problem (a crash) even slightly from the source of the problem makes it many times harder to fix in future.
Steve
-
In general the best thing to do with an access violation in some DLL you don't have source code for is to crash. It's amateurish to think that catching it solves any problems. If you think about it, it's self evident:
- Something went wrong.
- The unexpected event happened part way though a sequence of steps that probably should have been atomic.
I'll give some specific examples of the kind of problems that could occur:
- You were adding a node to a double-linked list when the access violation occurred. Now you have a node that is only partially linked in. Instead of crashing at the point of insertion you crash down the track when iterating over the list.
- The access violation happens after a call to
EnterCriticalSectionbut before the correspondingLeaveCriticalSection. Instead of crashing at the problem location an entirely different thread now locks up. - The crash was the last of a series of memory accesses of which some of the earlier ones (that didn't cause a crash) corrupted the heap. You'll now crash at some later time when allocating or freeing memory.
You could come up with a million of these examples. In most cases "recovering" from low-level exceptions by catching them turns a bad problem into a worse one. Sometimes crashing is a feature; don't make things worse trying to "fix" things. You may already know all this (you did mention something about terminating correctly), but I thought it best to point out just in case. There's also the fact that moving the manifestation of a problem (a crash) even slightly from the source of the problem makes it many times harder to fix in future.
Steve
I don't completely agree. While I agree that if there is an access violation in some DLL then program is in unstable state but crashing it (and letting OS tell you that you got a bad application) is bit extreme. I believe that such cases must be detected and a meaningful error must be displayed to user before closing the application. To me such application looks more professional. -Saurabh
-
I don't completely agree. While I agree that if there is an access violation in some DLL then program is in unstable state but crashing it (and letting OS tell you that you got a bad application) is bit extreme. I believe that such cases must be detected and a meaningful error must be displayed to user before closing the application. To me such application looks more professional. -Saurabh
The user will be more appreciative when the bug is fixed because the crash caused a report to be sent to Windows Error Reporting[^] which was download and analysed by the software publisher. A software company that develops software but doesn't collect these reports (or use some other 3rd party system of a similar nature) is doing it wrong. In most cases a custom message will be no more "meaningful" than a crash, but a crash is more constructive (it sends an error report to MS) and the state of the program has not altered by some custom "something ain't working" error dialog (and thus making analysis harder).
Steve
-
If you are calling DLL functions, check whether you are passing correct parameters, if any?
Can't hurt.
Steve