Application crashes - part 2

  • Thread starter Thread starter Julie
  • Start date Start date
J

Julie

Hi, I posted a few days ago and got some good responses, so thank you.

My application crashed again today (on the target machine with the
release build). [I was not using any of the code to set foreground
window, so we can leave that aside.]

Anyway, on Peter's suggestion, I had copied the .pdb file over to the
bin Release directory. (I assume that's the right place to put it?)
When the dialog indicating the segmentation fault appeared, I clicked
"debug", it brought up the debugger and it indicated that the seg
fault occurred in mscorlib.dll, and was an Argument out of range
exception.

So, this is what I know about the error. Do I need to copy the source
code over to this machine in order to get information about the stack
trace?
 
Julie said:
Hi, I posted a few days ago and got some good responses, so thank you.
Click to expand...
My application crashed again today (on the target machine with the
release build). [I was not using any of the code to set foreground
window, so we can leave that aside.]
Click to expand...
Anyway, on Peter's suggestion, I had copied the .pdb file over to the
bin Release directory. (I assume that's the right place to put it?)
Click to expand...

The .pdb file should be in the same directory where the executable is.
Typically, this would be a Program Files subdirectory, but if you've
installed the executable in a "bin Release directory" somewhere, then
sure…that would be the appropriate place.
When the dialog indicating the segmentation fault appeared, I clicked
"debug", it brought up the debugger and it indicated that the seg
fault occurred in mscorlib.dll, and was an Argument out of range
exception.
Click to expand...
So, this is what I know about the error. Do I need to copy the source
code over to this machine in order to get information about the stack
trace?
Click to expand...

In theory, should your own code actually _catch_ the exception, you
should be able to get a stack trace.  Alternatively, if you plan to
debug the code with a debugger, the .pdb should be sufficient.  Source
code isn't necessary in order to get a stack trace; it's only necessary
if you want to show source during debugging.

Note that given the information so far, it seems very likely that you're
simply passing some invalid value to a .NET method or property.

Anyway, in other words, given that you had the .pdb file installed and
started the debugger when the crash happened, you should have been able
to see the stack trace at that point.

Pete
Click to expand...

Hmm...strange that I didn't see the stack trace. I installed the .exe
using a .msi (installer), and then manually copied the .pdb file that
was built into the target machine's bin release directory, which was
where the .exe is.

Dumb question, but should I actually be able to see the source where
the crash occurred, and even the source for the upper level calls in
the stack? Or just a listing of the stack trace?
 
Julie said:
[...]
Dumb question, but should I actually be able to see the source where
the crash occurred, and even the source for the upper level calls in
the stack? Or just a listing of the stack trace?
Click to expand...

Just the stack trace.  To see source code, you need source code.
Click to expand...

Here's the latest. The software crashed today. I selected to debug,
and was presented with the option of debugging from Visual Studio 2005
or from the CLR Debugger (not sure what that is actually). I selected
Visual Studio 2005, it asked what my default language should be, I
selected C#, and then it told me that it couldn't debug from Visual
Studio. (The code itself was developed in Visual Studio 2005.) So, it
asked if I wanted to select a different debugger. I chose the only
other option: the CLR debugger. It opened this up, told me that it was
a System.NullReferenceException, but no stack trace/line of code info.

1) any idea why it might not be willing to debug from Visual Studio
2005?
2) What is the CLR debugger, and given that the .dbg file is loaded,
should I expect it to provide a stack trace?
 
Julie said:
[...]
Dumb question, but should I actually be able to see the source where
the crash occurred, and even the source for the upper level calls in
the stack? Or just a listing of the stack trace?
Click to expand...
Click to expand...
Just the stack trace.  To see source code, you need source code.
Click to expand...

Here's the latest. The software crashed today. I selected to debug,
and was presented with the option of debugging from Visual Studio 2005
or from the CLR Debugger (not sure what that is actually). I selected
Visual Studio 2005, it asked what my default language should be, I
selected C#, and then it told me that it couldn't debug from Visual
Studio. (The code itself was developed in Visual Studio 2005.) So, it
asked if I wanted to select a different debugger. I chose the only
other option: the CLR debugger. It opened this up, told me that it was
a System.NullReferenceException, but no stack trace/line of code info.

1) any idea why it might not be willing to debug from Visual Studio
2005?
2) What is the CLR debugger, and given that the .dbg file is loaded,
should I expect it to provide a stack trace?
Click to expand...

Err...I mean ".pdb" file, not ".dbg". :o)
 
Julie said:
[...] I chose the only
other option: the CLR debugger. It opened this up, told me that it was
a System.NullReferenceException, but no stack trace/line of code info.
Click to expand...
1) any idea why it might not be willing to debug from Visual Studio
2005?
Click to expand...

No.  Without specifics, it could be just about anything, even as any
possible problem should be very rare.
2) What is the CLR debugger, and given that the .dbg file is loaded,
should I expect it to provide a stack trace?
Click to expand...

http://msdn.microsoft.com/en-us/library/7zxbks7z(VS.80).aspx

I haven't used it, but I would expect it to be able to provide a stack
trace for a .NET program.  Possibly only if the entire stack trace is in
managed code though.

Note that your exception this time is different from the exception you
reported earlier.  This may point to some sort of data corruption
problem, or it could just be you have more than one bug.

Pete
Click to expand...

Yes, this was a second bug, and actually a reproducible one, which is
great!

I believe the reason I wasn't able to open the Visual Studio 2005
debugger to debug was because the user who was logged in did not have
permission to use the .pdb file. I gave them permission, so that seems
remedied.

Something else that's weird, though: At least a couple times, when we
clicked "Debug" from the original dialog (this is when you would
expect the "Just In Time Debugger dialog" to come up), nothing
happened. That's pretty annoying. Anyone have a clue about that?
 
Back
Top