back tracing a user.dmp

Hi,
I have a user.dmp (caused due to access violation). I have the stack and
other information (mapped from symbols and sources). What I want to do is,
set up breakpoints to trace the path which leads to this access violation.

This scenario (leading to access violation) is very hard to reproduce. So
setting up breakpoints and waiting for it to happen does not yield any
positive result.

Is it possible to do so?

thanks
Tushar


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Here’s one possible approach. If you can walk back up the stack to
find the last function of yours that was called before the access
violation occurred, you should be able to find the arguments to that
function. Take a look at what the args to that function are (in the
crashdump), and you can set a conditional breakpoint in WinDBG to break
whenever your function is called with arguments matching the ones which
lead to the access violation.
That way, if you break into windbg when the arguments are going to
cause the access violation, you can look at the stack trace to see
exactly how you were called…

sean

Tushar Bandopadhyay wrote:

Hi,
I have a user.dmp (caused due to access violation). I have the stack and
other information (mapped from symbols and sources). What I want to do is,
set up breakpoints to trace the path which leads to this access violation.

This scenario (leading to access violation) is very hard to reproduce. So
setting up breakpoints and waiting for it to happen does not yield any
positive result.

Is it possible to do so?

thanks
Tushar


You are currently subscribed to windbg as: xxxxx@stg.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

The key to getting a bug to reproing under the debugger is well getting
it to repro.

From the dump you should have an idea why the AV happened. Is it a
stack corruption? Heap corruption? Walk off the end of a valid page?
Null deference? Knowing the class of bug it falls in would give me some
idea as to how to attack it. For example the heap corruptor can often
be found with AppVerifier. But AppVerifier would not catch a stack
corruptor.

Some things to try:
Use conditional breakpoints to help make it more automated to
repro (see the bp docs)
It is possible that the debug heap that is used when a process
is started by the debugger is interfering with the repro. Start the
process normally and then attach the debugger to get the normal heap.
Hardware memory access breakpoints can help catch things like
memory corruptions if you know the memory location. See the docs for
ba. (I’ve found this handy for tracking down COM addref/release calls
to debug objects that leak or get freed too early. I set a ba w on the
refcount variable for the object with the problem.)
Use a debug build. Add more debugging code to provide more
validation of parameters, algorithms etc…

Other Runtime debugging tips:
If you are running the app on WinXP then using application
verifier (See KB Q286568). It has many checks which may catch the bug
(or others). The heap stuff in app verifier can help make hard to repro
AVs dealing with the heap easier to repro.
If you are running Win2k then you can use pageheap (the father
of AppVerifier). Not as good as running the app on XP with appverifier,
but better than nothing.
If you are using Visual Studio .NET you can use the /Gs compiler
flag to help catch stack buffer overruns
Use Boundschecker from Numega.

All these things have helped my find the bug for some of those hard
debugging scenerios. Often I’m left shaking my head and asking myself
why I didn’t do these in the first place rather than waste a day or more
trying other stuff.

Some compile time tips:
Turn up the warning level for the compiler. Make warnings
errors. At minimum I think warning level 3 with warnings as errors.
Personally I do warning level 4 with warnings as errors.
Use a tool like PC-Lint
Use other static code analysis tools.

These items have caught many potential problems before I even run the
code.

Since you have the dump of the failure I suggest spending some more time
analyzing the dump. I think the book “Debugging Applications” makes a
good point when it says that the debugger helps us gather information to
form theories as to the cause of the problem. Provided you know the
code you can then start looking in the code to prove your theory right
or wrong.

I hope one of those things help.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 6:07 AM
To: Kernel Debugging Interest List
Subject: [windbg] back tracing a user.dmp

Hi,
I have a user.dmp (caused due to access violation). I have the stack and
other information (mapped from symbols and sources). What I want to do
is,
set up breakpoints to trace the path which leads to this access
violation.

This scenario (leading to access violation) is very hard to reproduce.
So
setting up breakpoints and waiting for it to happen does not yield any
positive result.

Is it possible to do so?

thanks
Tushar

You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Thanks Nathan. The AV is due to hitting an assert. A condition which can
never occur (meaning neve expected to occur). No matter how hard we try to
simulate its not reproing. But agian, it suddenly leaves us some crash dump
when nobody is expecting it.

When I was working with the windbg shipped with platform SDK, I could set
breakpoints in the code and run (g) the user dump to its AV location. The
debugger won’t let me step the breakpoints but would stop their anyways to
indicate that an uninstantiated bp is hit. I got the flow pretty much from
there. I was wondering if I could do the same and possibly step thru.

It seems not. Thanks for you help.

thanks
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Friday, December 14, 2001 11:27 PM
Subject: [windbg] RE: back tracing a user.dmp

The key to getting a bug to reproing under the debugger is well getting
it to repro.

From the dump you should have an idea why the AV happened. Is it a
stack corruption? Heap corruption? Walk off the end of a valid page?
Null deference? Knowing the class of bug it falls in would give me some
idea as to how to attack it. For example the heap corruptor can often
be found with AppVerifier. But AppVerifier would not catch a stack
corruptor.

Some things to try:
Use conditional breakpoints to help make it more automated to
repro (see the bp docs)
It is possible that the debug heap that is used when a process
is started by the debugger is interfering with the repro. Start the
process normally and then attach the debugger to get the normal heap.
Hardware memory access breakpoints can help catch things like
memory corruptions if you know the memory location. See the docs for
ba. (I’ve found this handy for tracking down COM addref/release calls
to debug objects that leak or get freed too early. I set a ba w on the
refcount variable for the object with the problem.)
Use a debug build. Add more debugging code to provide more
validation of parameters, algorithms etc…

Other Runtime debugging tips:
If you are running the app on WinXP then using application
verifier (See KB Q286568). It has many checks which may catch the bug
(or others). The heap stuff in app verifier can help make hard to repro
AVs dealing with the heap easier to repro.
If you are running Win2k then you can use pageheap (the father
of AppVerifier). Not as good as running the app on XP with appverifier,
but better than nothing.
If you are using Visual Studio .NET you can use the /Gs compiler
flag to help catch stack buffer overruns
Use Boundschecker from Numega.

All these things have helped my find the bug for some of those hard
debugging scenerios. Often I’m left shaking my head and asking myself
why I didn’t do these in the first place rather than waste a day or more
trying other stuff.

Some compile time tips:
Turn up the warning level for the compiler. Make warnings
errors. At minimum I think warning level 3 with warnings as errors.
Personally I do warning level 4 with warnings as errors.
Use a tool like PC-Lint
Use other static code analysis tools.

These items have caught many potential problems before I even run the
code.

Since you have the dump of the failure I suggest spending some more time
analyzing the dump. I think the book “Debugging Applications” makes a
good point when it says that the debugger helps us gather information to
form theories as to the cause of the problem. Provided you know the
code you can then start looking in the code to prove your theory right
or wrong.

I hope one of those things help.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 6:07 AM
To: Kernel Debugging Interest List
Subject: [windbg] back tracing a user.dmp

Hi,
I have a user.dmp (caused due to access violation). I have the stack and
other information (mapped from symbols and sources). What I want to do
is,
set up breakpoints to trace the path which leads to this access
violation.

This scenario (leading to access violation) is very hard to reproduce.
So
setting up breakpoints and waiting for it to happen does not yield any
positive result.

Is it possible to do so?

thanks
Tushar

You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

_________________________________________________________

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Sounds like you are a bit confused on how to debug a dump file.

First get the latest and greatest Windbg from
http://www.microsoft.com/ddk/debugging. It sounds like you are using a
very old version. In any case the latest release v4.0.11 hasn’t gone
out in any platform SDK that I’m aware of, so what you have would be
older than that.

Second you don’t run dumps. The dump is a snapshot of the memory for
the process. You can’t go, step, set breakpoints, handle exceptions,
etc… (The debugger should give errors for these commands. It might
appear to accept a command, like setting a breakpoint, but since you
can’t execute code it is rather meaningless to do that.) You can switch
threads, get stack traces, view variables, unassemble, view memory but
that is really about it. And, of course, like always you need the
correct symbols loaded in order to have the best debugging experience.

Debugging a dump (or crashed process) requires a slightly different set
of skills than debugging a live process you can step through. It is
harder to reconstruct WHY the crash occurred than to step and watch the
bug get executed.

IMO it is worth spending time learning how to effectively debug from a
dump because sometimes that is all you have. Any information you can
get from the dump will help you in knowing what code to look at and how
to best attempt a repro.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 10:57 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: back tracing a user.dmp

Thanks Nathan. The AV is due to hitting an assert. A condition which can
never occur (meaning neve expected to occur). No matter how hard we try
to simulate its not reproing. But agian, it suddenly leaves us some
crash dump when nobody is expecting it.

When I was working with the windbg shipped with platform SDK, I could
set breakpoints in the code and run (g) the user dump to its AV
location. The debugger won’t let me step the breakpoints but would stop
their anyways to indicate that an uninstantiated bp is hit. I got the
flow pretty much from there. I was wondering if I could do the same and
possibly step thru.

It seems not. Thanks for you help.

thanks
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Friday, December 14, 2001 11:27 PM
Subject: [windbg] RE: back tracing a user.dmp

The key to getting a bug to reproing under the debugger is well getting
it to repro.

From the dump you should have an idea why the AV happened. Is it a
stack corruption? Heap corruption? Walk off the end of a valid page?
Null deference? Knowing the class of bug it falls in would give me some
idea as to how to attack it. For example the heap corruptor can often
be found with AppVerifier. But AppVerifier would not catch a stack
corruptor.

Some things to try:
Use conditional breakpoints to help make it more automated to repro (see
the bp docs) It is possible that the debug heap that is used when a
process is started by the debugger is interfering with the repro. Start
the process normally and then attach the debugger to get the normal
heap. Hardware memory access breakpoints can help catch things like
memory corruptions if you know the memory location. See the docs for
ba. (I’ve found this handy for tracking down COM addref/release calls
to debug objects that leak or get freed too early. I set a ba w on the
refcount variable for the object with the problem.) Use a debug build.
Add more debugging code to provide more validation of parameters,
algorithms etc…

Other Runtime debugging tips:
If you are running the app on WinXP then using application verifier (See
KB Q286568). It has many checks which may catch the bug (or others).
The heap stuff in app verifier can help make hard to repro AVs dealing
with the heap easier to repro. If you are running Win2k then you can use
pageheap (the father of AppVerifier). Not as good as running the app on
XP with appverifier, but better than nothing. If you are using Visual
Studio .NET you can use the /Gs compiler flag to help catch stack buffer
overruns Use Boundschecker from Numega.

All these things have helped my find the bug for some of those hard
debugging scenerios. Often I’m left shaking my head and asking myself
why I didn’t do these in the first place rather than waste a day or more
trying other stuff.

Some compile time tips:
Turn up the warning level for the compiler. Make warnings errors. At
minimum I think warning level 3 with warnings as errors. Personally I do
warning level 4 with warnings as errors. Use a tool like PC-Lint Use
other static code analysis tools.

These items have caught many potential problems before I even run the
code.

Since you have the dump of the failure I suggest spending some more time
analyzing the dump. I think the book “Debugging Applications” makes a
good point when it says that the debugger helps us gather information to
form theories as to the cause of the problem. Provided you know the
code you can then start looking in the code to prove your theory right
or wrong.

I hope one of those things help.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 6:07 AM
To: Kernel Debugging Interest List
Subject: [windbg] back tracing a user.dmp

Hi,
I have a user.dmp (caused due to access violation). I have the stack and
other information (mapped from symbols and sources). What I want to do
is, set up breakpoints to trace the path which leads to this access
violation.

This scenario (leading to access violation) is very hard to reproduce.
So setting up breakpoints and waiting for it to happen does not yield
any positive result.

Is it possible to do so?

thanks
Tushar

You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

_________________________________________________________

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

BTW, the command “!analyze -v” might give you some help. !analyze is
working great for kernel mode failures, but UM failure analysis is still
in the early development stage.

-----Original Message-----
From: Nathan Nesbit
Sent: Saturday, December 15, 2001 1:02 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: back tracing a user.dmp

Sounds like you are a bit confused on how to debug a dump file.

First get the latest and greatest Windbg from
http://www.microsoft.com/ddk/debugging. It sounds like you are using a
very old version. In any case the latest release v4.0.11 hasn’t gone
out in any platform SDK that I’m aware of, so what you have would be
older than that.

Second you don’t run dumps. The dump is a snapshot of the memory for
the process. You can’t go, step, set breakpoints, handle exceptions,
etc… (The debugger should give errors for these commands. It might
appear to accept a command, like setting a breakpoint, but since you
can’t execute code it is rather meaningless to do that.) You can switch
threads, get stack traces, view variables, unassemble, view memory but
that is really about it. And, of course, like always you need the
correct symbols loaded in order to have the best debugging experience.

Debugging a dump (or crashed process) requires a slightly different set
of skills than debugging a live process you can step through. It is
harder to reconstruct WHY the crash occurred than to step and watch the
bug get executed.

IMO it is worth spending time learning how to effectively debug from a
dump because sometimes that is all you have. Any information you can
get from the dump will help you in knowing what code to look at and how
to best attempt a repro.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 10:57 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: back tracing a user.dmp

Thanks Nathan. The AV is due to hitting an assert. A condition which can
never occur (meaning neve expected to occur). No matter how hard we try
to simulate its not reproing. But agian, it suddenly leaves us some
crash dump when nobody is expecting it.

When I was working with the windbg shipped with platform SDK, I could
set breakpoints in the code and run (g) the user dump to its AV
location. The debugger won’t let me step the breakpoints but would stop
their anyways to indicate that an uninstantiated bp is hit. I got the
flow pretty much from there. I was wondering if I could do the same and
possibly step thru.

It seems not. Thanks for you help.

thanks
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Friday, December 14, 2001 11:27 PM
Subject: [windbg] RE: back tracing a user.dmp

The key to getting a bug to reproing under the debugger is well getting
it to repro.

From the dump you should have an idea why the AV happened. Is it a
stack corruption? Heap corruption? Walk off the end of a valid page?
Null deference? Knowing the class of bug it falls in would give me some
idea as to how to attack it. For example the heap corruptor can often
be found with AppVerifier. But AppVerifier would not catch a stack
corruptor.

Some things to try:
Use conditional breakpoints to help make it more automated to repro (see
the bp docs) It is possible that the debug heap that is used when a
process is started by the debugger is interfering with the repro. Start
the process normally and then attach the debugger to get the normal
heap. Hardware memory access breakpoints can help catch things like
memory corruptions if you know the memory location. See the docs for
ba. (I’ve found this handy for tracking down COM addref/release calls
to debug objects that leak or get freed too early. I set a ba w on the
refcount variable for the object with the problem.) Use a debug build.
Add more debugging code to provide more validation of parameters,
algorithms etc…

Other Runtime debugging tips:
If you are running the app on WinXP then using application verifier (See
KB Q286568). It has many checks which may catch the bug (or others).
The heap stuff in app verifier can help make hard to repro AVs dealing
with the heap easier to repro. If you are running Win2k then you can use
pageheap (the father of AppVerifier). Not as good as running the app on
XP with appverifier, but better than nothing. If you are using Visual
Studio .NET you can use the /Gs compiler flag to help catch stack buffer
overruns Use Boundschecker from Numega.

All these things have helped my find the bug for some of those hard
debugging scenerios. Often I’m left shaking my head and asking myself
why I didn’t do these in the first place rather than waste a day or more
trying other stuff.

Some compile time tips:
Turn up the warning level for the compiler. Make warnings errors. At
minimum I think warning level 3 with warnings as errors. Personally I do
warning level 4 with warnings as errors. Use a tool like PC-Lint Use
other static code analysis tools.

These items have caught many potential problems before I even run the
code.

Since you have the dump of the failure I suggest spending some more time
analyzing the dump. I think the book “Debugging Applications” makes a
good point when it says that the debugger helps us gather information to
form theories as to the cause of the problem. Provided you know the
code you can then start looking in the code to prove your theory right
or wrong.

I hope one of those things help.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 6:07 AM
To: Kernel Debugging Interest List
Subject: [windbg] back tracing a user.dmp

Hi,
I have a user.dmp (caused due to access violation). I have the stack and
other information (mapped from symbols and sources). What I want to do
is, set up breakpoints to trace the path which leads to this access
violation.

This scenario (leading to access violation) is very hard to reproduce.
So setting up breakpoints and waiting for it to happen does not yield
any positive result.

Is it possible to do so?

thanks
Tushar

You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

_________________________________________________________

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Nathan ,
Thanks again. I had just about all the idea “required” on how to analyze a
crash
dump. But the windbg with my PSDK (surprisingly version 5.00.xxxxx,)
confused
me. It waits after the user dump is loaded.

So there is no other option but to run (go). Believe me it requires no
skills. So even
me (as per ur verdict no skills to debug a crash dump) saw this happen and
thought
maybe this is a newer version which will allow to step the flow. U want
screen shots ?

Now, why its “important to see and watch the bug get executed”. Well simply
because
its not a programming bug and the condithions that got introduced are not
probable.
And on which juncture they got introduced are most important and not the
dump.

But my last two attempts to explain this has gone waste, so let me make it
clear,
the reason for WHY is out of scope of this list.

thanks for your help
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Sunday, December 16, 2001 2:32 AM
Subject: [windbg] RE: back tracing a user.dmp

Sounds like you are a bit confused on how to debug a dump file.

First get the latest and greatest Windbg from
http://www.microsoft.com/ddk/debugging. It sounds like you are using a
very old version. In any case the latest release v4.0.11 hasn’t gone
out in any platform SDK that I’m aware of, so what you have would be
older than that.

Second you don’t run dumps. The dump is a snapshot of the memory for
the process. You can’t go, step, set breakpoints, handle exceptions,
etc… (The debugger should give errors for these commands. It might
appear to accept a command, like setting a breakpoint, but since you
can’t execute code it is rather meaningless to do that.) You can switch
threads, get stack traces, view variables, unassemble, view memory but
that is really about it. And, of course, like always you need the
correct symbols loaded in order to have the best debugging experience.

Debugging a dump (or crashed process) requires a slightly different set
of skills than debugging a live process you can step through. It is
harder to reconstruct WHY the crash occurred than to step and watch the
bug get executed.

IMO it is worth spending time learning how to effectively debug from a
dump because sometimes that is all you have. Any information you can
get from the dump will help you in knowing what code to look at and how
to best attempt a repro.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 10:57 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: back tracing a user.dmp

Thanks Nathan. The AV is due to hitting an assert. A condition which can
never occur (meaning neve expected to occur). No matter how hard we try
to simulate its not reproing. But agian, it suddenly leaves us some
crash dump when nobody is expecting it.

When I was working with the windbg shipped with platform SDK, I could
set breakpoints in the code and run (g) the user dump to its AV
location. The debugger won’t let me step the breakpoints but would stop
their anyways to indicate that an uninstantiated bp is hit. I got the
flow pretty much from there. I was wondering if I could do the same and
possibly step thru.

It seems not. Thanks for you help.

thanks
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Friday, December 14, 2001 11:27 PM
Subject: [windbg] RE: back tracing a user.dmp

The key to getting a bug to reproing under the debugger is well getting
it to repro.

From the dump you should have an idea why the AV happened. Is it a
stack corruption? Heap corruption? Walk off the end of a valid page?
Null deference? Knowing the class of bug it falls in would give me some
idea as to how to attack it. For example the heap corruptor can often
be found with AppVerifier. But AppVerifier would not catch a stack
corruptor.

Some things to try:
Use conditional breakpoints to help make it more automated to repro (see
the bp docs) It is possible that the debug heap that is used when a
process is started by the debugger is interfering with the repro. Start
the process normally and then attach the debugger to get the normal
heap. Hardware memory access breakpoints can help catch things like
memory corruptions if you know the memory location. See the docs for
ba. (I’ve found this handy for tracking down COM addref/release calls
to debug objects that leak or get freed too early. I set a ba w on the
refcount variable for the object with the problem.) Use a debug build.
Add more debugging code to provide more validation of parameters,
algorithms etc…

Other Runtime debugging tips:
If you are running the app on WinXP then using application verifier (See
KB Q286568). It has many checks which may catch the bug (or others).
The heap stuff in app verifier can help make hard to repro AVs dealing
with the heap easier to repro. If you are running Win2k then you can use
pageheap (the father of AppVerifier). Not as good as running the app on
XP with appverifier, but better than nothing. If you are using Visual
Studio .NET you can use the /Gs compiler flag to help catch stack buffer
overruns Use Boundschecker from Numega.

All these things have helped my find the bug for some of those hard
debugging scenerios. Often I’m left shaking my head and asking myself
why I didn’t do these in the first place rather than waste a day or more
trying other stuff.

Some compile time tips:
Turn up the warning level for the compiler. Make warnings errors. At
minimum I think warning level 3 with warnings as errors. Personally I do
warning level 4 with warnings as errors. Use a tool like PC-Lint Use
other static code analysis tools.

These items have caught many potential problems before I even run the
code.

Since you have the dump of the failure I suggest spending some more time
analyzing the dump. I think the book “Debugging Applications” makes a
good point when it says that the debugger helps us gather information to
form theories as to the cause of the problem. Provided you know the
code you can then start looking in the code to prove your theory right
or wrong.

I hope one of those things help.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 6:07 AM
To: Kernel Debugging Interest List
Subject: [windbg] back tracing a user.dmp

Hi,
I have a user.dmp (caused due to access violation). I have the stack and
other information (mapped from symbols and sources). What I want to do
is, set up breakpoints to trace the path which leads to this access
violation.

This scenario (leading to access violation) is very hard to reproduce.
So setting up breakpoints and waiting for it to happen does not yield
any positive result.

Is it possible to do so?

thanks
Tushar

You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com



Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com



Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Your windbg is 2 years old, buggy and obsolete. At the start of 2000
the debugger team completely re-wrote Windbg and the related debugging
techologies. Unfortunality, version number was reset causing confusion
such as yours. The latest release is 4.0.11 (released in Oct 2001 I
believe). I spent the last 2 years working on the debugger team making
the new Windbg, so I know what I’m talking about here.

Personally I couldn’t get the old windbg to run for more than 5 mins
without crashing, so I have no idea what you are talking about that it
lets you “run” then dump. But I feel confident is saying that it
certianly isn’t executing any code from the dump. All it might be doing
is reprocessing the exception and placing you in the right context. The
current debugger should be placing you in the faulting context when you
load a dump automaticly.

I think you misunderstood my comments. I made no mention of your
skills. I was just saying that debugging a dump is harder than
debugging live as one can’t do stuff like breakpoints, step, etc… I
also was trying to say that in a condition, such as yours, where
reproducing is very hard, one should spend extra time working on the
dump.

Obviously I can only talk in generalities since the only info you have
given is that the app Access Violates and that it is hard to repro. So
if the replies have been unhelpful, then perhaps more information from
you would enable people to offer better help.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Sunday, December 16, 2001 9:43 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: back tracing a user.dmp

Nathan ,
Thanks again. I had just about all the idea “required” on how to analyze
a crash dump. But the windbg with my PSDK (surprisingly version
5.00.xxxxx,) confused me. It waits after the user dump is loaded.

So there is no other option but to run (go). Believe me it requires no
skills. So even me (as per ur verdict no skills to debug a crash dump)
saw this happen and thought maybe this is a newer version which will
allow to step the flow. U want screen shots ?

Now, why its “important to see and watch the bug get executed”. Well
simply because its not a programming bug and the condithions that got
introduced are not probable. And on which juncture they got introduced
are most important and not the dump.

But my last two attempts to explain this has gone waste, so let me make
it clear, the reason for WHY is out of scope of this list.

thanks for your help
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Sunday, December 16, 2001 2:32 AM
Subject: [windbg] RE: back tracing a user.dmp

Sounds like you are a bit confused on how to debug a dump file.

First get the latest and greatest Windbg from
http://www.microsoft.com/ddk/debugging. It sounds like you are using a
very old version. In any case the latest release v4.0.11 hasn’t gone
out in any platform SDK that I’m aware of, so what you have would be
older than that.

Second you don’t run dumps. The dump is a snapshot of the memory for
the process. You can’t go, step, set breakpoints, handle exceptions,
etc… (The debugger should give errors for these commands. It might
appear to accept a command, like setting a breakpoint, but since you
can’t execute code it is rather meaningless to do that.) You can switch
threads, get stack traces, view variables, unassemble, view memory but
that is really about it. And, of course, like always you need the
correct symbols loaded in order to have the best debugging experience.

Debugging a dump (or crashed process) requires a slightly different set
of skills than debugging a live process you can step through. It is
harder to reconstruct WHY the crash occurred than to step and watch the
bug get executed.

IMO it is worth spending time learning how to effectively debug from a
dump because sometimes that is all you have. Any information you can
get from the dump will help you in knowing what code to look at and how
to best attempt a repro.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 10:57 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: back tracing a user.dmp

Thanks Nathan. The AV is due to hitting an assert. A condition which can
never occur (meaning neve expected to occur). No matter how hard we try
to simulate its not reproing. But agian, it suddenly leaves us some
crash dump when nobody is expecting it.

When I was working with the windbg shipped with platform SDK, I could
set breakpoints in the code and run (g) the user dump to its AV
location. The debugger won’t let me step the breakpoints but would stop
their anyways to indicate that an uninstantiated bp is hit. I got the
flow pretty much from there. I was wondering if I could do the same and
possibly step thru.

It seems not. Thanks for you help.

thanks
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Friday, December 14, 2001 11:27 PM
Subject: [windbg] RE: back tracing a user.dmp

The key to getting a bug to reproing under the debugger is well getting
it to repro.

From the dump you should have an idea why the AV happened. Is it a
stack corruption? Heap corruption? Walk off the end of a valid page?
Null deference? Knowing the class of bug it falls in would give me some
idea as to how to attack it. For example the heap corruptor can often
be found with AppVerifier. But AppVerifier would not catch a stack
corruptor.

Some things to try:
Use conditional breakpoints to help make it more automated to repro (see
the bp docs) It is possible that the debug heap that is used when a
process is started by the debugger is interfering with the repro. Start
the process normally and then attach the debugger to get the normal
heap. Hardware memory access breakpoints can help catch things like
memory corruptions if you know the memory location. See the docs for
ba. (I’ve found this handy for tracking down COM addref/release calls
to debug objects that leak or get freed too early. I set a ba w on the
refcount variable for the object with the problem.) Use a debug build.
Add more debugging code to provide more validation of parameters,
algorithms etc…

Other Runtime debugging tips:
If you are running the app on WinXP then using application verifier (See
KB Q286568). It has many checks which may catch the bug (or others).
The heap stuff in app verifier can help make hard to repro AVs dealing
with the heap easier to repro. If you are running Win2k then you can use
pageheap (the father of AppVerifier). Not as good as running the app on
XP with appverifier, but better than nothing. If you are using Visual
Studio .NET you can use the /Gs compiler flag to help catch stack buffer
overruns Use Boundschecker from Numega.

All these things have helped my find the bug for some of those hard
debugging scenerios. Often I’m left shaking my head and asking myself
why I didn’t do these in the first place rather than waste a day or more
trying other stuff.

Some compile time tips:
Turn up the warning level for the compiler. Make warnings errors. At
minimum I think warning level 3 with warnings as errors. Personally I do
warning level 4 with warnings as errors. Use a tool like PC-Lint Use
other static code analysis tools.

These items have caught many potential problems before I even run the
code.

Since you have the dump of the failure I suggest spending some more time
analyzing the dump. I think the book “Debugging Applications” makes a
good point when it says that the debugger helps us gather information to
form theories as to the cause of the problem. Provided you know the
code you can then start looking in the code to prove your theory right
or wrong.

I hope one of those things help.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 6:07 AM
To: Kernel Debugging Interest List
Subject: [windbg] back tracing a user.dmp

Hi,
I have a user.dmp (caused due to access violation). I have the stack and
other information (mapped from symbols and sources). What I want to do
is, set up breakpoints to trace the path which leads to this access
violation.

This scenario (leading to access violation) is very hard to reproduce.
So setting up breakpoints and waiting for it to happen does not yield
any positive result.

Is it possible to do so?

thanks
Tushar

You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com



Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com



Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Nathan,
I guess I over reacted. I still use version 3.0.0020.0 and have no complains
expect
live K mode debugging. I got the dump context fine. But as I already
mentioned,
haven’t got the dump repro again (4 days and running :().

thanks for your help
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Tuesday, December 18, 2001 3:26 AM
Subject: [windbg] RE: back tracing a user.dmp

Your windbg is 2 years old, buggy and obsolete. At the start of 2000
the debugger team completely re-wrote Windbg and the related debugging
techologies. Unfortunality, version number was reset causing confusion
such as yours. The latest release is 4.0.11 (released in Oct 2001 I
believe). I spent the last 2 years working on the debugger team making
the new Windbg, so I know what I’m talking about here.

Personally I couldn’t get the old windbg to run for more than 5 mins
without crashing, so I have no idea what you are talking about that it
lets you “run” then dump. But I feel confident is saying that it
certianly isn’t executing any code from the dump. All it might be doing
is reprocessing the exception and placing you in the right context. The
current debugger should be placing you in the faulting context when you
load a dump automaticly.

I think you misunderstood my comments. I made no mention of your
skills. I was just saying that debugging a dump is harder than
debugging live as one can’t do stuff like breakpoints, step, etc… I
also was trying to say that in a condition, such as yours, where
reproducing is very hard, one should spend extra time working on the
dump.

Obviously I can only talk in generalities since the only info you have
given is that the app Access Violates and that it is hard to repro. So
if the replies have been unhelpful, then perhaps more information from
you would enable people to offer better help.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Sunday, December 16, 2001 9:43 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: back tracing a user.dmp

Nathan ,
Thanks again. I had just about all the idea “required” on how to analyze
a crash dump. But the windbg with my PSDK (surprisingly version
5.00.xxxxx,) confused me. It waits after the user dump is loaded.

So there is no other option but to run (go). Believe me it requires no
skills. So even me (as per ur verdict no skills to debug a crash dump)
saw this happen and thought maybe this is a newer version which will
allow to step the flow. U want screen shots ?

Now, why its “important to see and watch the bug get executed”. Well
simply because its not a programming bug and the condithions that got
introduced are not probable. And on which juncture they got introduced
are most important and not the dump.

But my last two attempts to explain this has gone waste, so let me make
it clear, the reason for WHY is out of scope of this list.

thanks for your help
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Sunday, December 16, 2001 2:32 AM
Subject: [windbg] RE: back tracing a user.dmp

Sounds like you are a bit confused on how to debug a dump file.

First get the latest and greatest Windbg from
http://www.microsoft.com/ddk/debugging. It sounds like you are using a
very old version. In any case the latest release v4.0.11 hasn’t gone
out in any platform SDK that I’m aware of, so what you have would be
older than that.

Second you don’t run dumps. The dump is a snapshot of the memory for
the process. You can’t go, step, set breakpoints, handle exceptions,
etc… (The debugger should give errors for these commands. It might
appear to accept a command, like setting a breakpoint, but since you
can’t execute code it is rather meaningless to do that.) You can switch
threads, get stack traces, view variables, unassemble, view memory but
that is really about it. And, of course, like always you need the
correct symbols loaded in order to have the best debugging experience.

Debugging a dump (or crashed process) requires a slightly different set
of skills than debugging a live process you can step through. It is
harder to reconstruct WHY the crash occurred than to step and watch the
bug get executed.

IMO it is worth spending time learning how to effectively debug from a
dump because sometimes that is all you have. Any information you can
get from the dump will help you in knowing what code to look at and how
to best attempt a repro.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 10:57 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: back tracing a user.dmp

Thanks Nathan. The AV is due to hitting an assert. A condition which can
never occur (meaning neve expected to occur). No matter how hard we try
to simulate its not reproing. But agian, it suddenly leaves us some
crash dump when nobody is expecting it.

When I was working with the windbg shipped with platform SDK, I could
set breakpoints in the code and run (g) the user dump to its AV
location. The debugger won’t let me step the breakpoints but would stop
their anyways to indicate that an uninstantiated bp is hit. I got the
flow pretty much from there. I was wondering if I could do the same and
possibly step thru.

It seems not. Thanks for you help.

thanks
Tushar

----- Original Message -----
From: “Nathan Nesbit”
To: “Kernel Debugging Interest List”
Sent: Friday, December 14, 2001 11:27 PM
Subject: [windbg] RE: back tracing a user.dmp

The key to getting a bug to reproing under the debugger is well getting
it to repro.

From the dump you should have an idea why the AV happened. Is it a
stack corruption? Heap corruption? Walk off the end of a valid page?
Null deference? Knowing the class of bug it falls in would give me some
idea as to how to attack it. For example the heap corruptor can often
be found with AppVerifier. But AppVerifier would not catch a stack
corruptor.

Some things to try:
Use conditional breakpoints to help make it more automated to repro (see
the bp docs) It is possible that the debug heap that is used when a
process is started by the debugger is interfering with the repro. Start
the process normally and then attach the debugger to get the normal
heap. Hardware memory access breakpoints can help catch things like
memory corruptions if you know the memory location. See the docs for
ba. (I’ve found this handy for tracking down COM addref/release calls
to debug objects that leak or get freed too early. I set a ba w on the
refcount variable for the object with the problem.) Use a debug build.
Add more debugging code to provide more validation of parameters,
algorithms etc…

Other Runtime debugging tips:
If you are running the app on WinXP then using application verifier (See
KB Q286568). It has many checks which may catch the bug (or others).
The heap stuff in app verifier can help make hard to repro AVs dealing
with the heap easier to repro. If you are running Win2k then you can use
pageheap (the father of AppVerifier). Not as good as running the app on
XP with appverifier, but better than nothing. If you are using Visual
Studio .NET you can use the /Gs compiler flag to help catch stack buffer
overruns Use Boundschecker from Numega.

All these things have helped my find the bug for some of those hard
debugging scenerios. Often I’m left shaking my head and asking myself
why I didn’t do these in the first place rather than waste a day or more
trying other stuff.

Some compile time tips:
Turn up the warning level for the compiler. Make warnings errors. At
minimum I think warning level 3 with warnings as errors. Personally I do
warning level 4 with warnings as errors. Use a tool like PC-Lint Use
other static code analysis tools.

These items have caught many potential problems before I even run the
code.

Since you have the dump of the failure I suggest spending some more time
analyzing the dump. I think the book “Debugging Applications” makes a
good point when it says that the debugger helps us gather information to
form theories as to the cause of the problem. Provided you know the
code you can then start looking in the code to prove your theory right
or wrong.

I hope one of those things help.

-----Original Message-----
From: Tushar Bandopadhyay [mailto:xxxxx@yahoo.com]
Sent: Friday, December 14, 2001 6:07 AM
To: Kernel Debugging Interest List
Subject: [windbg] back tracing a user.dmp

Hi,
I have a user.dmp (caused due to access violation). I have the stack and
other information (mapped from symbols and sources). What I want to do
is, set up breakpoints to trace the path which leads to this access
violation.

This scenario (leading to access violation) is very hard to reproduce.
So setting up breakpoints and waiting for it to happen does not yield
any positive result.

Is it possible to do so?

thanks
Tushar

You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com



Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com



Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

_________________________________________________________

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com