WinDebug question

[Hiten]

Hi,

I have couple questions on debugging and would appreciate if someone can
answer them.

1. Is it possible to run WinDbg without installing Windows Debugger tools? I
need to run debugger at client site but not sure if they can install Debugger
tools on their production box. If its possible to run windebug without
installing, what are the files I would need to provide to client? Is it
possible for ADPlus (cdb)?

2. What is the difference between dump taken by ADPlus and WindDbg? If I
take crash dump using ADPlus, will it be same as WinDbg crash dump? because,
When I debug my application using WinDebug, and if an exception is thrown, it
gives me line by line stack trace, where as when I take a dump ( using
command .dump /mf mydump.dmp), and open it in WinDbg, it does not give me
stack trace of on which line exception occured. Is it possible to get this by
any means? Am I missing anything? My app is a .net App and I am using Sos.dll
to get clrstack

Any answer or suggestion would be appreciated

Thanks,

[Skywing [MVP]]

You can use xcopy or any other bulk copy tool to just copy the whole DTW
install over and it will "just work" without any registry settings or
whatnot. The MSI is just a convenience and isn't required.

As for ADPlus, are you using it in hang mode or crash mode? If you are
using it in hang mode then there will be no exception record to go to. If
in crash mode, you should be able to use the `.ecxr' command to display the
exception information (this works for any minidump with an exception record
associated with it when the dump was written), IIRC - though it has been
awhile since I have used ADPlus, so I may be misremembering.

--
Ken Johnson (Skywing)
Windows SDK MVP

"Hiten" <Hi...@discussions.microsoft.com> wrote in message
news:58C21462-1784-4570...@microsoft.com...

[Hiten]

Thanks Skywing for your answer.

Can you tell me if there is any difference between dump taken using WinDbg
and CDB? And what command should give me code line on which exception was
thrown? As I mentioned, if I debug App using WinDbg I get detail by line
number on which exception was thrown, but when I analyze the dump, I am not
gettting line information on which the exception was thrown...

Thanks in advance,
Hiten

[Skywing [MVP]]

No, if you use the same command and are using the same version of cdb as
WinDbg, the dump will be the same. They are just different front-ends
around the same debugger engine.

If you aren't getting line information then I would guess that you don't
have symbols for the module loaded. Remember that for dump file debugging,
you typically need both the symbols (.pdb) *and* the binary
(.exe/.dll./sys/whatever) to be available on the debugger computer in order
to get symbols to work fully. This typically involves putting both files in
your symbol path (use `.sympath' to get or set the current symbol path).

--
Ken Johnson (Skywing)
Windows SDK MVP

"Hiten" <Hi...@discussions.microsoft.com> wrote in message

news:88377A6F-41B4-41F4...@microsoft.com...

[Hiten]

Thanks Skywing. This was a great help for me to understand whats needed for
debugging.

[Hiten]

Skywing,

What is the difference between Dr.Watson Dump and WinDbg dump? Are they
same? If they are then I can use it to take a dump and that way,I don't have
to give any executable to client to run it on their box.

Is there a way I can automate getting dump? I may not be able to run
ADPlus.vbs on client box because of some security issues of running script on
production box, however if I can provide some command line stapes to start
and attach debugger to my app, than I can use it to create crash dump and get
it from my client. (A way to do what ADPlus script is doing but using CBD or
NTSD debugger to get crash dump)

thanks,
Hiten

[Skywing [MVP]]

Depends on the arguments you pass to `.dump'. DrWatson usually fairly
minimalistic dumps by default, although you can control this to some extent
in DrWatson's config options.

Anyways, you could do something like `cdb -g -G -p <pid> -c ".dump /ma
c:\dump.dmp;qd"'. This would attach the debugger, wait for the first event
to cause the process to stop in the debugger, write a complete minidump and
then detach the debugger. You might want to tweak the event filters a bit
so that first chance exceptions don't cause the process to breakin.

ADPlus is probably easier though, as it handles all of that kind of thing
for you behind the scenes.

--
Ken Johnson (Skywing)
Windows SDK MVP

"Hiten" <Hi...@discussions.microsoft.com> wrote in message

news:6CB37323-EB99-4D0F...@microsoft.com...

[Hiten]

Skywing,

Thanks a lot for your reply.

I have another question. As I mentioned in one of the question, When I tries
to debug the dump, I am not getting line numbers. Here is what I am doing...

1. I have a .net App which has couple buttons to throw exception.
2. I run it on production box in winDebug. Click on app to throw exception
3. Create mini dump after exception (.dump /mf test.dmp)
4. Copy the dump file to my test m/c.
5. Open the dump file in WinDbg,then load sos.dll (.load .\clr10\sos.dll)
6. tries to analyze clrStack (!clrStack -all)

In 6th stap I am getting exception information, but not getting line number
where exception occured, however, If i tries to debug app directly in WinDbg,
i.e. open App in WinDebug, Load sos.dll, Run Debugger, click on App to throw
exception, and run !ClrStack, it gives me line number where exception
occured.

Any idea what could be missing when I am debugging app on test m/c. using
dump instead of live debugging?

Thanks,
Hiten

[Hiten]

Skywing,

I tried to run cdb -g -G -p <pid> -c ".dump /ma c:\dump.dmp;qd" command by
replacing pid with proper process id on my box, but it did not generated the
dump file.I did loaded assemblies and displayed break point but no dump file.
FYI: I am testing an application that throws an application exception and
File not found exception.

any idea what could be wrong?

[Drew Bliss [MSFT]]

Managed .NET code is a much different beast than unmanaged code. The
runtime (the CLR) that provides managed support can implement things however
it likes for managed code, it doesn't have to use the normal OS mechanisms.
This means that exception processing may be different, in particular
unhandled exception support can and is much different from the basic OS
support.

CLR exceptions do not break by default, you can enable this with sxe clr, at
the risk of stopping a lot. The CLR provides a top-level unhandled
exception filter and may or may not let exceptions hit the traditional
OS/debugger breaks.

Finally, debugging managed code is much different as code generation and
thus debugging support has to be dynamic. Everything to do with debugging
managed code has to go through CLR translations. That's why you have to use
sos to debug managed code instead of just having the debugger work. It also
means that things like source line lookup involve extra steps that may
interfere. If you are using CLR v1.1, for example, very little beyond sos
will work since there is no special debug support. If you are using CLR
v2.0 there is special debug support that you need to have around, you can
use the .cordll command to see if that is getting loaded when you are
debugging.

"Hiten" <Hi...@discussions.microsoft.com> wrote in message

news:4BEC5817-FDEF-4638...@microsoft.com...

[Hiten]

Dreq,

Thanks for the details. I have to debug dump from 1.1 framework and when I
tried to run the .cordll in WinDbg, it gave me message "CLR DLL status: No
load attempts" Any idea what does this mean? I could not find help on this
command either.

Any suggestion of how to get line information where the exception occured
from the crash dump? I have 2nd chance AccessViolation crash dump. some of
the lines of the dump are

0x12f2f0 0x108e864 System.Text.StringBuilder
0x12f2f4 0x1089e50 System.Object[]
0x12f2f8 0x108e4cc System.String An unhandled exception has occurred in y
0x12f2fc 0x1089278 System.OutOfMemoryException
0x12f300 0x10895f8 System.Windows.Forms.ThreadExceptionDialog
0x12f344 0x1089700 System.Security.FrameSecurityDescriptor
0x12f360 0x1089700 System.Security.FrameSecurityDescriptor
0x12f364 0x1089278 System.OutOfMemoryException
0x12f368 0x10895f8 System.Windows.Forms.ThreadExceptionDialog
0x12f370 0x10895f8 System.Windows.Forms.ThreadExceptionDialog

Can you give me some hint on how to debug this information? or how to
interpreat it to get to line/method on which exception could have occured?

thanks,
Hiten

[Drew Bliss [MSFT]]

There is no special managed debug support for CLR v1.1, .cordll is not
supposed to do anything.

I would recommend contacting a CLR support alias or newsgroup for
suggestions on how to debug your particular managed code problem.

"Hiten" <Hi...@discussions.microsoft.com> wrote in message

news:0F5FFC1C-4F0E-4393...@microsoft.com...