Crash Dump Analysis and Debugging Portal

You have to use special breakpoint commands for managed code. Sos includes a
!bpmd command, but it's rather limited. If you add sosex.dll as well, you'll
be a little better off, but for this type of debugging Visual Studio gives
you a lot more. John Robbins wrote a post regarding sosex.dll and
breakpoints which you can find here:

Has anybody tried to get the source server working with clearcase
dynamic views?
Any advice is well come.
Cheers,
Volker

Thanks Brian!
I have using .load to load the SOS package. And I have tried I can use
extension commands like !threads.
But when I use bu or bm to set a breakpoint, for example, bu Foo (Foo is a
function in class FooUtility), there is error message like -- "Operation not
supported by integrated managed debugging.". How to solve it?

You need to load sos.dll to make WinDbg work with managed code. John Robbins
wrote an introduction you may find helpful:
[link]
Regards,
Brian Rasmussen [C# MVP]

We got rid of these breakins by stopping using remote debugger
connections.

Hello everyone,
When I use bu or bm to set a breakpoint into a process running C#, there is
always error message like -- "Operation not supported by integrated managed
debugging."
How to make WinDbg support .Net application debug?
(I made a search to find some similar questions, but not quite helpful.)

我是用IA-32的.
6.9版的dt *不能用了.

I have an asp.net (.net 2.0) app that has multiple app domains. I can
set breakpoints when i know the exact name of the dll, object,method
using !bpmd but what about when i don't know the name exactly? In
unmaged code i can simply use the 'x' command to view the symbols and
set the breaks such as
x ole32*!*

"Julian" wrote that THREE MONTHS AGO and hasn't been back since.
Start a new thread rather than reply to a dead one.

"Julian" <msfor...@tiger2.notthisbit.de mon.co.uk> wrote in
[...]
Do you still have this issue, Julian? A 'me too' here - same symptoms,
different system.
Did you ever get it resolved?
Sander

I am trying to debug a SQL 2005 dump file - I have the correct public
symbol path (it gets the kernel symbols, etc.) but for some reason it
cannot find the SQL symbols - what am I doing wrong here?
0:075> !sym noisy
noisy mode - symbol prompts on
0:075> .reload
..
DBGHELP: c:\symbols\ntdll.dll\45D70AD8c 0000\ntdll.dll - OK

On x64, in code compiled without register homing.
On x86, in any sufficiently complex and optimized code.
On ia64 retail bits, it almost always never work.
If you debug checked un-optimized code on x86, then
you are in the best case scenario.

`!address <0x12345678>`
is your best friend.
If `!address` tells you that you are in a module,
then, try to use `ln <address>`.
Give the example you posted in the past, you have a stack overrun,
and, you are executing from the stack, that for machines with
the NX policy enabled, it going to trigger an access violation.

Hey, thanks, thats great!

Thanks Ivan,
Great reply! A further question, when dv command will not work in your
experience? In my current debugging, it works fine.
regards,
George

Thanks Ivan,
What I am trying to do is to solve a sort of specific issues, when there is
OS error box which indicates my application is broken at some address (e.g.
0x12345678), because of unhandled exception or something corruption (e.g.
stack or access violation). I want to find out what actually resides in

Resolved. I located a shortcut for windbg that had 'Run this program as
an administrator' set on the compatibility tab. Once this was no longer
set windbg behaved as expected.
cheers
Gerard.

Not sure what you're referring to by a "desktop integrity check". Do you have
any references I can use to do some self education in this area ?
For refrence, I'm running Vista Home Premium on a Gateway laptop. Its my own
personal machine, not some corporate box .... ie. there's no "support"-ware
locking it down.

Correct, there is no way. It depends entirely on the context and on the
interpretation that is being given.

Maybe some desktop integrity check kicks-in, and, you can use
only a command-line debugger.
In that case, you can always set-up a remote, and connect to
ntsd with windbg via a localhost connection