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

• Anonymous
  January 19, 2006
  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!

• Anonymous
  January 19, 2006
  In Windbg? or are you talking about Visual Studio?

• Anonymous
  January 19, 2006
  Your are doing a great job. Especially Managed debugging using windbg.

• Anonymous
  January 20, 2006
  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.

• Anonymous
  January 20, 2006
  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.
  =]

• Anonymous
  January 20, 2006
  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.

• Anonymous
  January 20, 2006
  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 ;-)

• Anonymous
  January 20, 2006
  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.

• Anonymous
  January 20, 2006
  The comment has been removed

• Anonymous
  January 20, 2006
  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)

• Anonymous
  January 20, 2006
  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.

• Anonymous
  January 22, 2006
  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.

• Anonymous
  January 24, 2006
  Good article! Very useful!
  Remote debugging is something I would be interested in.
  
  cheers,
  
  nik

• Anonymous
  January 24, 2006
  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.
  

• Anonymous
  January 27, 2006
  The comment has been removed

• Anonymous
  January 29, 2006
  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.

• Anonymous
  February 02, 2006
  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.
  

• Anonymous
  February 07, 2006
  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
  

• Anonymous
  February 07, 2006
  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.

• Anonymous
  February 16, 2006
  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

• Anonymous
  February 16, 2006
  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

• Anonymous
  February 16, 2006
  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.
  

• Anonymous
  February 16, 2006
  The comment has been removed

• Anonymous
  June 24, 2006
  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.
  

• Anonymous
  June 25, 2006
  That looks right, so I am not sure why it is not working... sorry:(

• Anonymous
  July 04, 2006
  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.

• Anonymous
  November 09, 2006
  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).

• Anonymous
  November 09, 2006
  The comment has been removed

• Anonymous
  September 10, 2007
  The comment has been removed

• Anonymous
  September 10, 2007
  The comment has been removed

• Anonymous
  September 10, 2007
  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.

• Anonymous
  April 02, 2008
  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.

• Anonymous
  April 02, 2008
  Hi Bob, Next time I have such an issue I will try to post about it. Tess

• Anonymous
  August 18, 2009
  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.

• Anonymous
  March 23, 2016
  The comment has been removed

• Anonymous
  July 05, 2016
  Thank you Tess!