Crash Debugging Problems

  • Thread starter Thread starter Jason Smith
  • Start date Start date
J

Jason Smith

I'm rather new with vb.net and I'm having problems debugging a large vb.net
application.

The application is randomly crashing at two locations with "referenced
memory at 0x0" violations. My try-catch blocks are not trapping these
exceptions.

Sysinternals' procexp places the two crash addresses in ntdll.dll, offsets
2a84 and 2b6a - both in RtlLogStackBackTrace.

A Dr Watson of a crash shows most of the threads are in the same code above
the ending address of the last dll.

My nubie questions:

Why don't the try-catch blocks catch these exceptions? The entire process is
wrappered by one.

Does anyone have any idea what is going on in ntdll!RtlLogStackBacktrace?
Any ideas why I would have crashes in there?

What are the threads executing? The last dll ends at 7c396000 and Dr Watson
shows almost every thread in code around 7ffe0304.

Does anyone have a suggestion on how to trap my faults, or at least narrow
down where I should be looking?
 
Hi ,
You can try and use Application.ThreadException to handle unhandled
exceptions. It is documented at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemwindowsformsapplicationclassthreadexceptiontopic.asp

But since you are receving an Access Violation, handling this would not be
a good idea since this error occurs because memory has been overwritten,
which is not supposed to.

You can go to http://www.microsoft.com/whdc/ddk/debugging/installx86.mspx
to install the debugging tools for windows and then download it and install
it. It will install the tools at
c:\program files\debugging tools for windows\

Once it is done, start your application and then go to the command prompt
at the folder where the debugging tools are installed and then type

adplus -crash -pn "YourAppName.exe"

When the crash occurs it will generate a folder such as "Crash_Mode..." in
the C:\prgoram files\debugging tools for windows\.. This folder will be
atleast 30 to 100 MB. There will be a file with extension .dmp. You need to
load this .dmp file in windbg which is also installed with the debugging
tools. After you load this you will have to use several commands to get
information out of the dump. The help that comes with it is very good. It
has several commands. But the process of finding out the cause for the
problem is pretty tough and would require an expert in debugging to find
out whats going on. If this problem is very critical, then I would suggest
that you can create a support incident with Microsoft and the appropriate
team will engage their Escalation Engineers and might be possible to find
out the root cause for the problem.

Thanks

Anand Balasubramanian
Microsoft, Visual Basic .NET

This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only. Thanks
 
Back
Top