Request for feedback


Not sure if anyone is reading this blog, but if you are and there is something specific you want me to blog about please let me know.

On my TODO list right now i have

  • Debugging managed memory leaks
  • Automating debugging with .shell and .foreach etc.
  • Debugging .net 2.0 applications

but I want this blog to be a useful resource, so rather than just blogging about what interests me, let me know what interests you:).
And I’m also interested in getting feedback on if my blog posts are too long, or too short, or too detailed or not detailed enough…
or if i should just stick to debugging, and stop writing boring blogs:)

Until next time…


Comments (34)

  1. Jason says:

    Hi, I’m not sure if you have already blogged about Remote Debugging or not, but that is always something I hear people having trouble with (Setting up, permissions etc), so an article on that would be great!

  2. Tess says:

    In Windbg? or are you talking about Visual Studio?

  3. snaveen says:

    Your are doing a great job. Especially Managed debugging using windbg.

  4. Colin says:

    Tess, Your blog rocks. I don’t have any specific areas to suggest, but suggest you keep wrting when you come accross stuff you think should be more widely known because it’s REALLY usefull stuff.

    Thanks!

    Colin.

  5. Hasani says:

    I usually don’t post comments. I just use the "Rate" feature.

    More windbg tutorials would be great. Especially debugging mixed mode code and pure managed code.

    My knowledge on windbg has been based on what I found on google and on http://blogs.msdn.com/mvstanton/default.aspx.

    Your post on associating windbg files with dumps was excellent because it was a time saver for loading some dumps I was working on.

    Debugging managed memory leaks seems like an interesting topic. For now, I’ve been using scitech’s profiler.

    It would be great if you can stick to just windbg instead of vs.net for debugging articles because windbg is free and is a small install and sometimes, I want to debug the problem in realtime.. Windbg doesn’t require a reboot upon installation which allows me to download, install, attach, dump, look at stuff, detach.

    =]

  6. Hasani says:

    1 more thing.. Is SIEExtPub.dll past of the windbg install yet?

    I remember having to scour the internet for it, as it was a seperate download I got from some obscure website =/

    It had some useful functions like critlist, waitlist, and showstring.

    critlist & showstring = major timersaver.

  7. Mark Capaldi says:

    Keep up the good work!

    I too would like to see information about Remote Debugging.

    Also, any tips on remote debugging VB6 applications would help me out right now ;-)

  8. Luciano Caixeta says:

    A friend recently show me your blog and trust me, every minute reading the posts is worth. I think that the size of the post doesn’t matter, if you need 20 or 2000 lines to explaind something, do it. Keep up the good work.

  9. Tess says:

    wow, thanks a lot for all the comments, i’ll keep writing then:) next one comming up will be a case study of a memory leak and should be done within the next few days.

    In regards to the remote debugging topic, I am still curious if it is windbg or visual studio that interests, and also what types of environments (over the internet, or on the same LAN, or through a terminal services session etc. and also if it is debugging a service or a windows application as how you attach depends a little what windows station you started the application in, on second thought, i’ll probably add a little of everything once i start writing it:))

    Windbg doesn’t allow you to attach to a remote process but i’ll be happy to talk about tips and tricks to debug things remotely by starting cdb on the remote machine and then attaching to a remote session. It can be a bit tricky to get it working.

    For the VB6 topic, I’m sorry to say it’s not something I generally deal with, but I want to recommend my colleague Mark Long (his blog is in the blogs i read list) he knows a lot more about VB6 than anyone on this earth would ever care to know…

  10. Tess says:

    Oh, and on sieextpub.dll, it’s not a part of the windbg.exe package but i’ll try to figure out where to get it and write some posts about it. Some of the functions that Hasani mentioned like !critlist is a must for low CPU hang debugging (gives you all threads waiting for critical sections)

  11. One thing I can’t ever find is a "managed debugging for noobs" article that covers taking memory dumps of a process on demand and by creating an exception handler of sorts that does it for you, then loading this dump into mdbg or windbg, loading the symbols, and doing a bit of inspection.

    It seems there is plenty of info out there on the power of debugging memory dumps, and plenty about the details of what you can do within the dbg tools, but there’s just so little on helping people bridge that gap.

  12. Tess says:

    I noticed this so I wrote a post called Back to Basics on how to gather dumps, and in the 40.000 exceptions post you can see how you can create a config file for gathering logs/dumps for all your exceptions, but I’ll keep doing more of these as ideas come up.

  13. nik says:

    Good article! Very useful!

    Remote debugging is something I would be interested in.

    cheers,

    nik

  14. Tal Rosen says:

    Good blog,keep on the good work…

    Please don’t neglect the unmanaged world.

    Also I would be happy to read about real cases when GFlags/Verifier helped you troubleshoot strange bugs.

  15. allandcp says:

    I think consensus is that people are reading this "boring blog" and *LOVING* it. I’m a big fan.

    Since I tend to see more apps having memory pressure than high cpu. I’d like to see…

    Difference between pinning and things being rooted and how to solve both.

    How does 64 bit (with 2.0) change the debugging landscape – specifically what new things to look for and the tools to support looking.

  16. Tess says:

    With 64 bit one of the big challenges will be using full dumps as the dumps can get very big so there is some ongoing work in improving managed debugging in mini-dumps. I don’t have a 64 bit machine right now so I can’t make up good samples but as things come up I’ll make sure to write notes on it.

    For pinning, I have on my todo-list to look at some pinning samples but in short, pinning is another way of rooting an object but apart from rooting, the object can also not be moved during a garbage collection, so the heapsegment can get very fragmented. Maoni (in the blogs i read) has some good discussions on pinning and how to use the GC efficiently.

    The way to determine if you have a pinning problem is to look for if the number of free objects is a very large set of the total heap (say 30% or more), and look for long running remoting calls or other unmanaged calls where objects are pinned before doing the unmanaged call.

  17. Ole says:

    Your blog is fantastic! Keep it up.

    Memory issues, especially in relation to caching is what I find the most interesting.

    Also, articles about ways to hook into the GC would be interesting.

  18. Craig Boland says:

    Wow! I just started learning how to debug CLR apps, so I’m glad to have come across your blog. I look fwd to reading the posts.

    I have a topic suggestion. The main reason I’ve begun learning how to use WinDbg and the CLR Profiler is because I want to add something like a "runtime review" (think "code review") to our development process. The vision is to periodically, during/after stress testing, use these tools to examine runtime operation. We build medium/large internal ASP.NET applications, and I’ve learned that with server apps, proper memory management is critical. I’d like to know if there’s a memory problem before our application either dies in production, or otherwise performs poorly.

    So I would certainly appreciate if you would write about disgnosing memory problems as a form of "preventive maintenance", though post-mortem topics are equally welcome. ;-)

    Another topic is to cover what’s in debugging with .NET 2.0/VS2005 (and the latest Windows Debugging Tools) over .NET 1.1/VS2003. Many of the debugging articles and white papers on MSDN site seem to be outdated this way, making it difficult to learn from them.

    PS –

    Hansi asked about SIEExtPub.dll. I found it here:

    http://www.microsoft.com/downloads/info.aspx?na=22&p=3&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3d7c6ec49c-a8f7-4323-b583-6a7a6aeb5e66%26DisplayLang%3den

  19. Tess says:

    Hi Craig,

    Sooo nice to hear that people are stress testing:)  

    Just to make sure I know what you are talking about with preventive maintenance, are you talking about comparing memory usage throughout the stress test and determining where your mem is going (when there isn’t a leak as such) to get a feel for how your app is doing?

    I might at some point (always the disclaimer:)) get into debugging with VS 2005 and other like debugging tools, on some post, but only if i find some really cool thing to blog about.  In general i probably won’t, for one single reason, I really dont know that much about it, so it would just be random ramblings.

    I know someone who does though:)http://blogs.msdn.com/jmstall – Mike Stall, do check out his blog.

    About 2.0 with Windbg, most of the debugging stays the same,  but there are some differences so comming up I will try to show samples from 2.0 rather than 1.1 from now on. In most cases you won’t know the difference though…

    ty for the sieextpub.dll link btw, its an awesome debugger extension.

  20. Hi Craig, Tess,

    I also like the sieextpub.dll a lot.

    Especially !comcalls, !critlist and !waitlist!

    Unfortunately they do not seem to work with version 6.6.3.5

    Have a look at my post here:

    http://groups.google.com/group/microsoft.public.windbg/browse_frm/thread/6644eb4021527e73/f1381841e768113f#f1381841e768113f

    Volker

  21. Tess says:

    Hi Volker,

    I just posted back to that newsgroup post. Siextpub.exe does work in that version of windbg. In fact most extensions are debugger independent. The problem is likely that the correct symbols for ntdll or kernel32 are not loaded. The extension uses these for locks etc.

    If you still can’t get it working !locks will give you the same information as !critsec but in a slightly different and "not as nice" format.

    Tess

  22. Hi Tess,

    thanks a lot for your effort! Actually I’m using MS symbol server, so symbols should be ok (I checked the ones for ntll and kernel32).

    Please have a look at my example. This is a hang scenario:

    0:006> ~* k

      0  Id: 1860.1fd4 Suspend: 1 Teb: 7ffdf000 Unfrozen

    ChildEBP RetAddr  

    0012f8c0 7c90e9ab ntdll!KiFastSystemCallRet

    0012f8c4 7c8094f2 ntdll!ZwWaitForMultipleObjects+0xc

    0012f960 77564822 kernel32!WaitForMultipleObjectsEx+0x12c

    0012f9dc 664013e6 ole32!CoWaitForMultipleHandles+0x100

    0012fa30 664021c5 DATAAC_1!CServiceModule::Run+0xcb

    0012fa54 66401c5f DATAAC_1!CServiceModule::Start+0x4c

    0012ff24 6641d007 DATAAC_1!wWinMain+0x27e

    0012ffc0 7c816d4f DATAAC_1!wWinMainCRTStartup+0x15b

    0012fff0 00000000 kernel32!BaseProcessStart+0x23

      1  Id: 1860.1f58 Suspend: 1 Teb: 7ffde000 Unfrozen

    ChildEBP RetAddr  

    00a4feb8 7c90e31b ntdll!KiFastSystemCallRet

    00a4febc 7c80cbd9 ntdll!ZwRemoveIoCompletion+0xc

    00a4fee8 664185e6 kernel32!GetQueuedCompletionStatus+0x29

    00a4ff78 66418594 DATAAC_1!CTraceBPL::EventsWorker+0x3f

    00a4ff80 77c3a3b0 DATAAC_1!CTraceBPL::InitThreadFunc+0x13

    00a4ffb4 7c80b50b msvcrt!_endthreadex+0xa9

    00a4ffec 00000000 kernel32!BaseThreadStart+0x37

      2  Id: 1860.998 Suspend: 1 Teb: 7ffdd000 Unfrozen

    ChildEBP RetAddr  

    00f3fdf4 7c90e9ab ntdll!KiFastSystemCallRet

    00f3fdf8 7c8094f2 ntdll!ZwWaitForMultipleObjects+0xc

    00f3fe94 7c809c86 kernel32!WaitForMultipleObjectsEx+0x12c

    00f3feb0 66419a63 kernel32!WaitForMultipleObjects+0x18

    00f3ff08 6641571d DATAAC_1!CClientEventThreadManager::Post+0xc4

    00f3ff54 6641562d DATAAC_1!CInstrumentControl::MyEventDispatcherThread+0x71

    00f3ff80 77c3a3b0 DATAAC_1!CInstrumentControl::EventDispatcherThread+0x4a

    00f3ffb4 7c80b50b msvcrt!_endthreadex+0xa9

    00f3ffec 00000000 kernel32!BaseThreadStart+0x37

      3  Id: 1860.1aac Suspend: 1 Teb: 7ffdc000 Unfrozen

    ChildEBP RetAddr  

    0103fe2c 7c90e9c0 ntdll!KiFastSystemCallRet

    0103fe30 7c91901b ntdll!ZwWaitForSingleObject+0xc

    0103feb8 7c90104b ntdll!RtlpWaitForCriticalSection+0x132

    0103fec0 66419b67 ntdll!RtlEnterCriticalSection+0x46

    0103ff14 66415a15 DATAAC_1!CClientEventThreadManager::CleanUpDeadClients+0x3a

    0103ff54 66415820 DATAAC_1!CInstrumentControl::MyCleanupThread+0x160

    0103ff80 77c3a3b0 DATAAC_1!CInstrumentControl::CleanupThread+0x4c

    0103ffb4 7c80b50b msvcrt!_endthreadex+0xa9

    0103ffec 00000000 kernel32!BaseThreadStart+0x37

      4  Id: 1860.1114 Suspend: 1 Teb: 7ffdb000 Unfrozen

    ChildEBP RetAddr  

    0114fe18 7c90e399 ntdll!KiFastSystemCallRet

    0114fe1c 77e76703 ntdll!NtReplyWaitReceivePortEx+0xc

    0114ff80 77e76c22 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0xf4

    0114ff88 77e76a3b RPCRT4!RecvLotsaCallsWrapper+0xd

    0114ffa8 77e76c0a RPCRT4!BaseCachedThreadRoutine+0x79

    0114ffb4 7c80b50b RPCRT4!ThreadStartRoutine+0x1a

    0114ffec 00000000 kernel32!BaseThreadStart+0x37

      5  Id: 1860.1d08 Suspend: 1 Teb: 7ffda000 Unfrozen

    ChildEBP RetAddr  

    0124ff24 7c90e9c0 ntdll!KiFastSystemCallRet

    0124ff28 7c8025db ntdll!ZwWaitForSingleObject+0xc

    0124ff8c 774fe407 kernel32!WaitForSingleObjectEx+0xa8

    0124ffa8 774fe444 ole32!CRpcThread::WorkerLoop+0x5c

    0124ffb4 7c80b50b ole32!CRpcThreadCache::RpcWorkerThreadEntry+0x1b

    0124ffec 00000000 kernel32!BaseThreadStart+0x37

      6  Id: 1860.1998 Suspend: 1 Teb: 7ffd9000 Unfrozen

    ChildEBP RetAddr  

    0141f4ac 7c90e9c0 ntdll!KiFastSystemCallRet

    0141f4b0 7c91901b ntdll!ZwWaitForSingleObject+0xc

    0141f538 7c90104b ntdll!RtlpWaitForCriticalSection+0x132

    0141f540 66419956 ntdll!RtlEnterCriticalSection+0x46

    0141f56c 66414ee8 DATAAC_1!CClientEventThreadManager::Stop+0x22

    0141f574 66402b40 DATAAC_1!CInstrumentControl::OnAfterUnadvise+0xc

    0141f58c 77e79dc9 DATAAC_1!CProxy_IDAQInstrumentControlNotify<CInstrumentControl>::Unadvise+0x3c

    0141f5a8 77ef321a RPCRT4!Invoke+0x30

    0141f9ac 77ef3bf3 RPCRT4!NdrStubCall2+0x297

    0141fa04 77600c31 RPCRT4!CStdStubBuffer_Invoke+0xc6

    0141fa44 77600bdb ole32!SyncStubInvoke+0x33

    0141fa8c 7750f237 ole32!StubInvoke+0xa7

    0141fb64 7750f15c ole32!CCtxComChnl::ContextInvoke+0xe3

    0141fb80 77600b11 ole32!MTAInvoke+0x1a

    0141fbb0 776009bc ole32!AppInvoke+0x9c

    0141fc84 77600715 ole32!ComInvokeWithLockAndIPID+0x2e0

    0141fcd0 77e7988c ole32!ThreadInvoke+0x1cd

    0141fd04 77e797f1 RPCRT4!DispatchToStubInC+0x38

    0141fd58 77e7971d RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x113

    0141fd7c 77e8a067 RPCRT4!RPC_INTERFACE::DispatchToStub+0x84

      7  Id: 1860.1f4c Suspend: 1 Teb: 7ffd6000 Unfrozen

    ChildEBP RetAddr  

    0171fe18 7c90e399 ntdll!KiFastSystemCallRet

    0171fe1c 77e76703 ntdll!NtReplyWaitReceivePortEx+0xc

    0171ff80 77e76c22 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0xf4

    0171ff88 77e76a3b RPCRT4!RecvLotsaCallsWrapper+0xd

    0171ffa8 77e76c0a RPCRT4!BaseCachedThreadRoutine+0x79

    0171ffb4 7c80b50b RPCRT4!ThreadStartRoutine+0x1a

    0171ffec 00000000 kernel32!BaseThreadStart+0x37

      8  Id: 1860.1cc4 Suspend: 1 Teb: 7ffd7000 Unfrozen

    ChildEBP RetAddr  

    0161fdec 7c90e9ab ntdll!KiFastSystemCallRet

    0161fdf0 7c8094f2 ntdll!ZwWaitForMultipleObjects+0xc

    0161fe8c 77564822 kernel32!WaitForMultipleObjectsEx+0x12c

    0161ff08 664110dd ole32!CoWaitForMultipleHandles+0x100

    0161ff58 66410ffc DATAAC_1!CInstrument::ChipDetectThread+0x82

    0161ff80 77c3a3b0 DATAAC_1!CInstrument::ChipDetectThreadProc+0x36

    0161ffb4 7c80b50b msvcrt!_endthreadex+0xa9

    0161ffec 00000000 kernel32!BaseThreadStart+0x37

      9  Id: 1860.1d68 Suspend: 1 Teb: 7ffd5000 Unfrozen

    ChildEBP RetAddr  

    0181f860 7c90e3ed ntdll!KiFastSystemCallRet

    0181f864 77e7c968 ntdll!ZwRequestWaitReplyPort+0xc

    0181f8b0 77e7a716 RPCRT4!LRPC_CCALL::SendReceive+0x228

    0181f8bc 776016bf RPCRT4!I_RpcSendReceive+0x24

    0181f8d8 776011b6 ole32!ThreadSendReceive+0xf5

    0181f8f4 7760109a ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+0x13d

    0181f9d4 7751047c ole32!CRpcChannelBuffer::SendReceive2+0xb9

    0181fa40 77510414 ole32!CAptRpcChnl::SendReceive+0xab

    0181fa94 77ef3db5 ole32!CCtxComChnl::SendReceive+0x113

    0181fab0 77ef3eac RPCRT4!NdrProxySendReceive+0x43

    0181fe8c 77ef3e42 RPCRT4!NdrClientCall2+0x1fa

    0181feac 77e89aa4 RPCRT4!ObjectStublessClient+0x8b

    0181febc 66419e4e RPCRT4!ObjectStubless+0xf

    0181fefc 66419490 DATAAC_1!CProxy_IDAQInstrumentControlNotify<CInstrumentControl>::Fire_StatusChanged+0xa2

    0181ff50 66419298 DATAAC_1!CClientEventThread::MyClientEventThread+0xa5

    0181ff80 77c3a3b0 DATAAC_1!CClientEventThread::ClientEventThread+0x8c

    0181ffb4 7c80b50b msvcrt!_endthreadex+0xa9

    0181ffec 00000000 kernel32!BaseThreadStart+0x37

     10  Id: 1860.538 Suspend: 1 Teb: 7ffad000 Unfrozen

    ChildEBP RetAddr  

    01c1fc20 7c90e9ab ntdll!KiFastSystemCallRet

    01c1fc24 7c8094f2 ntdll!ZwWaitForMultipleObjects+0xc

    01c1fcc0 77564822 kernel32!WaitForMultipleObjectsEx+0x12c

    01c1fd3c 6640d21e ole32!CoWaitForMultipleHandles+0x100

    01c1fd5c 6640dfd7 DATAAC_1!CHelpers::WaitForSingleObject+0x36

    01c1fd94 6640e0c6 DATAAC_1!CInstrument::OnError+0x9f

    01c1fda8 5ec0ffac DATAAC_1!CInstrument::OnError+0x17

    01c1fe04 5ec09591 BioReader!CProxy_IDAQBioReaderEvents<CCuReader>::Fire_OnError+0x9c

    01c1fe48 5ec08cca BioReader!CCuReader::FireError+0x122

    01c1ff00 5ec18499 BioReader!CCuReader::NewDataReceived+0x14f

    01c1ff3c 5ec183df BioReader!CSimulator::ReadSimulationFile+0x76

    01c1ff50 5ec18331 BioReader!CSimulator::RunThread+0xf

    01c1ff80 77c3a3b0 BioReader!CSimulator::RunThreadProc+0x4a

    01c1ffb4 7c80b50b msvcrt!_endthreadex+0xa9

    01c1ffec 00000000 kernel32!BaseThreadStart+0x37

    # 11  Id: 1860.1ac4 Suspend: 1 Teb: 7ffd4000 Unfrozen

    ChildEBP RetAddr  

    0129ffc8 7c9507a8 ntdll!DbgBreakPoint

    0129fff4 00000000 ntdll!DbgUiRemoteBreakin+0x2d

    0:006> !sieextpub.help

    SIE Extension – Version 1.75

     !kdall               = Executes kd for the full range of current thread’s stack

     !filevers            = Show version and paths of all loaded modules

     !critlist            = List CritSecs that threads are waiting on

     !waitlist            = Lists handles each thread is blocking on

     !sr2 <addr>          = Get target process/thread from 1st param of SendReceive2

     !waitreply <addr>    = Get target process/thread from 2nd param of RequestWaitReplyPort

     !comcalls            = Show COM calls on all threads

     !vbcheck <module>    = Check Unattended Execution/Retained In Memory settings

     !vbcheckall          = Check UE/RIM settings on all modules

     !stackrange          = Shows start/end stack addresses of current thread

     !rangesearch         = Search an address range for values within a range

     !showstring <addr>   = Prints an ASCII string

     !showstringw <addr>  = Prints a double byte string

     !showvariant <addr>  = Shows the contents of a variant object

     !showctime <val>     = Converts a ctime DWORD to a string

    Step commands repeat a command from a starting address.

    Use %x and %d as placeholders in command.

    For example: !stepptr 04002C34 4 dc %x

     !stepval  <val>  <count> <cmd> = Repeats command on each value

     !stepptr  <addr> <count> <cmd> = Repeats command on each pointer

    0:006> !critlist

    No threads waiting on critical sections.

    0:006> !waitlist

    0:006> !comcalls

    Thread 9 – MTA

    Target Process ID: 3d476aae = 1028090542

    Target Thread  ID: 00006000  (STA – Possible junk values)

    0:006> !critsec

    0:006> !locks

    CritSec DATAAC_1!TraceBPL+c0 at 6642f2e0

    LockCount          -4

    RecursionCount     -3

    OwningThread       0

    EntryCount         0

    ContentionCount    0

    *** Locked

    CritSec +8139d8 at 008139d8

    LockCount          0

    RecursionCount     1

    OwningThread       1aac

    EntryCount         0

    ContentionCount    0

    *** Locked

    CritSec +813a3c at 00813a3c

    LockCount          2

    RecursionCount     1

    OwningThread       998

    EntryCount         2

    ContentionCount    2

    *** Locked

    Scanned 410 critical sections

    !locks is better than nothing but it can’t beat !waitlist, as it also lists the waiters.

  23. Tess says:

    I honestly cant say then without looking at the dump why critlist isnt working, but it would appear that thread #2 ID = 1860.998 would be interesting to look at as a potential culprit for the hang.  

    Keeping in mind that it might just be a slowdown, so perhaps if you take a new dump in a few seconds the critsec owner might have changed.

    I dont think the reason !critlist isnt working has anything to do with the windbg version, i still think it has something to do with the symbols.  Can you lmv mntdll and lmv mkernel32 and show the output?

  24. Steph says:

    I know this is quite old and all, but I’m seeing the same kind of problems running on WOW64.  Here’s the output of lmv, as requested:

    0:006> lmv mntdll

    start    end        module name

    7d600000 7d6f0000   ntdll      (pdb symbols)          c:windowssymbolswntdll.pdbD48FB9E83A8648C4947DF85AA16C26372wntdll.pdb

       Loaded symbol image file: C:WINDOWSsystem32ntdll.dll

       Image path: C:WINDOWSsystem32ntdll.dll

       Image name: ntdll.dll

       Timestamp:        Thu Mar 24 21:29:40 2005 (42437794)

       CheckSum:         000C2D24

       ImageSize:        000F0000

       File version:     5.2.3790.1830

       Product version:  5.2.3790.1830

       File flags:       0 (Mask 3F)

       File OS:          40004 NT Win32

       File type:        2.0 Dll

       File date:        00000000.00000000

       Translations:     0409.04b0

       CompanyName:      Microsoft Corporation

       ProductName:      Microsoft® Windows® Operating System

       InternalName:     ntdll.dll

       OriginalFilename: ntdll.dll

       ProductVersion:   5.2.3790.1830

       FileVersion:      5.2.3790.1830 (srv03_sp1_rtm.050324-1447)

       FileDescription:  NT Layer DLL

       LegalCopyright:   © Microsoft Corporation. All rights reserved.

    0:006> lmv mkernel32

    start    end        module name

    7d4c0000 7d5f0000   kernel32   (pdb symbols)          c:windowssymbolswkernel32.pdbA45A226167C84E5C95E55E442F5375ED2wkernel32.pdb

       Loaded symbol image file: C:WINDOWSsyswow64kernel32.dll

       Image path: C:WINDOWSsyswow64kernel32.dll

       Image name: kernel32.dll

       Timestamp:        Thu Mar 24 21:29:40 2005 (42437794)

       CheckSum:         000F6488

       ImageSize:        00130000

       File version:     5.2.3790.1830

       Product version:  5.2.3790.1830

       File flags:       0 (Mask 3F)

       File OS:          40004 NT Win32

       File type:        2.0 Dll

       File date:        00000000.00000000

       Translations:     0409.04b0

       CompanyName:      Microsoft Corporation

       ProductName:      Microsoft® Windows® Operating System

       InternalName:     kernel32

       OriginalFilename: kernel32

       ProductVersion:   5.2.3790.1830

       FileVersion:      5.2.3790.1830 (srv03_sp1_rtm.050324-1447)

       FileDescription:  Windows NT BASE API Client DLL

       LegalCopyright:   © Microsoft Corporation. All rights reserved.

  25. Tess says:

    That looks right, so I am not sure why it is not working… sorry:(

  26. Steph says:

    No problem.  I ended up finding what I needed by inspecting the memory itself.  It’s too bad the source code for these extensions isn’t available.

  27. Ricky says:

    Is it possible to debug script (vbscript/jscript on ASP specifically) via WinDbg?  If so, I’d love to see a post on that subject (since many of us deal with ASP/ASP.NET hybrid sites).

  28. Tess says:

    Hi Ricky,

    I may write a post later on, but I am trying to focus on .net debugging.

    However, if you have a hang in an ASP app for example or a crash you can take a dump in the same way I have described for managed hangs and crashes (with adplus or debugdiag) and then use debugdiag to parse the file to get what line of code you were in in the ASP page when it happened.

  29. Reg says:

    Any chance to see a new example of using adplus configuration files? The file format has changed since the original entry was posted. I’ve been trying to get it to only log when Execution Engine Exception occurs, but to no avail.

  30. Tess says:

    Hi Reg,

    I am not really sure which original post you are talking about regarding Execution Engine Exceptions so if you could let me know which, that would be great, and what it is that no longer works.

    I would recommend using

    adplus -crash -NoDumpOnFirst -p <PID>  

    for starters and then look at the log file if the exit process dump doesnt show you what you need.

    Thanks

    Tess

  31. Tess says:

    Sorry, just realized when i looked at one of my recent Fatal EEs that it now generates a breakpoint exception so you could use something like this as your config file

    adplus -p <PID> -c myconfig.cfg

    where myconfig.cfg looks like this…

    <ADPlus>

       <Settings>

           <RunMode> CRASH </RunMode>

    <Sympath> c:symcache </Sympath>

       </Settings>

       <Exceptions>

    <Option>  NoDumpOnFirstChance  </Option>

    <Option>  NoDumpOnSecondChance  </Option>

    <Config>

             <Code>  AllExceptions </Code>

             <Actions1> Log;Time  </Actions1>

             <ReturnAction1> GN </ReturnAction1>

             <Actions2> Void  </Actions2>

             <ReturnAction2> GN </ReturnAction2>

          </Config>  

          <Config>

             <Code>  bpe </Code>

             <Actions1> FullDump </Actions1>

             <ReturnAction1> GN </ReturnAction1>

             <Actions2> Void  </Actions2>

             <ReturnAction2> GN </ReturnAction2>

          </Config>  

    <Config>

             <Code>  epr </Code>

             <Actions1> FullDump </Actions1>

             <ReturnAction1> GN </ReturnAction1>

             <Actions2> Void  </Actions2>

             <ReturnAction2> GN </ReturnAction2>

          </Config>  

       </Exceptions>

    </ADPlus>

    Note: if you dont even want a log for other exceptions you can change the all exceptions setting to void but I usually find it quite useful to see what happened just before the Fatal EE.

  32. Bob Riddle says:

    I have recently been drafted into analyzing IIS dumps and am trying to climb the learning curve.  Your blog posts and the resulting discussion have been invaluable.  

    But one issue on which I have not seen much discussion is that of following legacy COM calls from IIS’s thread pool thru the context switch to the STA thread.   I’d love a tutorial post on this general area.

    I am working with legacy apps and have not had the good fortune to have sufficient symbols for the SIEExtPub extension’s "!comcalls" function to work.

    I’m interested in following this trail with and without ASPCompat functionality.  I’d like to locate the actual COM objects involved.  I’d like to understand following this trail when working both with directly invoked COM objects and .Net wrapped (COM Interop) COM objects.

  33. Tess says:

    Hi Bob,

    Next time I have such an issue I will try to post about it.

    Tess

  34. Venkatesh says:

    Hi Tess,

    Could you also provide notes on the various debugging tools and the in-built debugging tools to be be used in .net 2.0. version.