WinDbg.info - Forum

Thread: Detail analysis of crashme.exe

sudhir — Fri, 05 Mar 2010 11:28:53 +0100

Hi
Can you please elaborate how to analyze dump using Crashme.exe
it will be very helpful.

Regards
Sudhir

Thread: Determing cause of access denied - USN Journal

Will Steele — Mon, 01 Mar 2010 18:44:04 +0100

I have a Vista SP1 workstation on which I would like to shrink the primary partition. I have run a few tools to try and consolidate data to the front of the drive so I can then run the shrink functionality of disk management. The tools have shown me that the problem lies in a few USN journal files near the end of the drive that will not move (or allow deletion.) When I run the fsutil command logged in under the local machine administrator account against the drive I get this error (command and error shown below):

C:\Users\Administrator>fsutil usn deletejournal /D C:
Error: Access is denied.

Someone suggested on the Technet forums I then ran the shell as system using this command:

C:\users\administrators>psexec -s fsutil usn deletejournal /D C:
Error: Access is denied.

fsutil exited on MYMACHINE with error code 1.

As I suspected, system privileges did not allow me to delete the entries. So, I am looking to use WinDbg to figure out what process or system structure is preventing the utility from deleting these files. I suspect it is a "feature" but I don't know if it is a bug. How would you debugging experts approach this issue?

Thread: See in Memory Descriptor List whats on

Steffen78 — Mon, 22 Feb 2010 13:29:12 +0100

Hello Girls and Boys,

i have a problem with a w2k3 server ent. sp2. The machine is an x86 32bit system with an MS SQL 2005 installed for enteo. the server part of enteo is ionstalled to. antivirus is mcafee.

Now the problem, the "non paged pool" is running out of free space till the server is crashing. the "biggest" pooltag in poolmon is the "mdl".

Is there a way to analyze with driver is exhausting the mdl. can i analyze this problem with a full memory dump or should i take the driver verifier for this?

thank you very much for your help.

sorry about my english.

Thread: Using WinDbg to examine ASP.NET applications - reply by: Will Steele

Will Steele — Thu, 18 Feb 2010 16:43:00 +0100

Awesome. Thanks for the pointers and the link to the PDF. I had not even seen that one yet. Looking forward to working with it. Again, much appreciated.

Thread: Unable to load image ntoskrnl.exe - reply by: Will Steele

Will Steele — Thu, 18 Feb 2010 16:37:10 +0100

I feel dumb. While thumbing though the glossary of my copy of Windows Internals I noticed there are two kernel .exe files: ntkrnlmp and ntoskrnl. The first (ntkrnlmp) is for multiprocessor machines. The second (ntoskrnl) is for single processor machines. The light bulb came on and I verified that my machine (a newer dual processor laptop) would not have the single processor .exe. I went to double check with my co-worker who did in fact say the machine which generated the dump is in fact a single-processor appliance. It was a very simple piece of the puzzle I didn't have. Thanks for the steps I will be sure to keep those close by in case I need them for a real problem. :)

Thread: Debugging minGW/GCC built DLL in Visual Studio? - reply by: Edward

Edward — Wed, 17 Feb 2010 19:01:43 +0100

thank for the pointers.
'looks like PDB absorbed in other IDE that already absorbs PECOFF/STABS and PECOFF/DWARF is a more realistic path. (GCC 4 is pushing out PECOFF/DWARF to complicate issues)....

Thread: Articles/tutorials - reply by: Robert Kuster

Robert Kuster — Wed, 17 Feb 2010 15:48:00 +0100

Hi Raminder,

welcome and thanks for your suggestion. To be honest, I'm not yet sure how much I would like to open the article part to the public. It certainly would have advantages, because simply more stuff would be on-line. On the other side I would lose control about the quality of what is on-line. Nevertheless, it is very likely that I will turn at least a part of the article section public so anyone could make contributions there. In the meantime just let me know if you have something really interesting to write on and we will figure out something.

Kind regards,
Robert

Thread: Other forums - reply by: Robert Kuster

Robert Kuster — Sun, 17 Jan 2010 18:32:03 +0100

Hi Will,

From my point of view your questions perfectly fit to the forum; that is what it actually is about. Help people with WinDbg, regardless to what their initial skills might be. Hm, if you nevertheless want other places there are several. You might check Syinternals or CodeProject's debug section; the Forum at Open System Resources (OSR), or the handy blog from Dmitry called Dumpanalysis; then there is Debuginfo and so on. But after all you could also take a day off, read WinDbg. From A to Z!, and play around with CrashMe along the way. In fact WinDbg. From A to Z! answered virtually all of your questions so far. ;)

Hope to see you around, Robert

Thread: Can handled exceptions be seen with WinDbg - reply by: Robert Kuster

Robert Kuster — Sun, 17 Jan 2010 18:07:40 +0100

Hi Will,

here I go again. Sorry for the little delay this time.
Can handled exceptions be seen with WinDbg
Short answer: Nope. A handled/dismissed exception isn't an exception anymore.

Long answer: It depends. The first thing one should know about exceptions is that on Windows (either the environment is Win32, MFC, .NET, or the kernel) exceptions are handled by the OS. To us exceptions are made available through language extensions, for example through the try & except constructs in C++ or C#. Thus it is the OS or more precisely its exception dispatcher that takes care and dispatches exceptions. From the perspective of the exception dispatcher there are two different situations to cover:

A debugger is attached to the application in question
No debugger is attached to the application

In case there is a debugger the exception dispatcher does the following:

Attempts to notify the process's debugger (say, WinDbg). This is known as a first-chance exception.
If WinDbg handles the exception (gH - go, exception handled) that's it. In this case the exception dispatcher won't notify anyone else about the exception because it has been dismissed.
If WinDbg didn't handle the exception, the OS then tries to locate a frame-base exception filter (a C++ or C# catch statement, for instance).
Again, if the exception filter handles the exception that's it. In this case the exception dispatcher won't notify anyone else about the exception.
If along the way nobody handled the exception, the exception dispatcher will notify the associated debugger again. This is known as a second-chance or last-chance exception.
Again, if the associated debugger handles the exception that's it. Your application will continue to run fine as if nothing has happened.
But if the associated debugger doesn't handle even the second chance exception (for instance, in WinDbg: gN - go not handled command) the process will terminate.

The bottom line:

if a debugger is attached, this debugger will always be notified about any exception in the first place (first-chance exception)
once an exception is handled there is no way to display it in a debugger thereafter; no debugger will be notified about handled exceptions

Finally please check WinDbg. From A to Z! once again.

Refer to slides 17-20 about the exception dispatcher and exceptions in general.
Refer to slides 85-86 about debugging exceptions with WinDbg.
Refer to slides 89-92 about event filters in WinDbg. In particular you should enable CLR exceptions and CLR notification exceptions for managed applications as otherwise WinDbg will ignore them altogether.

Said all that there is one more tool to be aware off called Application Verifier. Application Verifier is a runtime verification tool that monitors an application's interaction with the Windows OS. Among other things it profiles and tracks all (handled an unhandled) exceptions that occur within a process. Again, check out WinDbg. From A to Z! and refer to slides 97-102. While Application Verifier will display handled exceptions to you, note that it is just a tracking/logging tool of events that occurred in the past. By no means it will halt a debugger on handled exceptions since this isn't how exceptions were meant to work in the first place.

Last but not least: You might also try out the sos!DumpAllExceptions command.

I hope this helps, RK :)

Thread: How do source code files help? - reply by: Robert Kuster

Robert Kuster — Sun, 17 Jan 2010 17:54:49 +0100

Hi Will,

we are somewhat out of luck here, I'm afraid. By default WinDbg doesn't support debugging of managed code natively - at least not in its public releases. See explanation here: No CLR support in the latest debugger release . The only WinDbg release really supporting it was version 6.7.5.0 which was mistakenly made public. Maybe you can still find it somewhere. If so, you'll be able to see call stacks with functions names, source code information, and so on in almost the same way as you see it for C++ applications.

To keep it short: You can use WinDbg to obtain some extra information for managed applications via its SOS or SOSEX extension. But in order too turn it into a really useful debugger for manged applications stick to WinDbg version 6.7.5.0

I hope this helps, RK

Thread: RSS Feed - reply by: Will Steele

Will Steele — Wed, 06 Jan 2010 22:47:12 +0100

I see it now. Maybe adding it to the set of icons on the top left (new thread, reply, un/subscribe, favorite) or right side (above Forum Tools) would have gotten my attention. It was hiding from me. Thanks again.

Thread: Question about COFF deprecation - reply by: Robert Kuster

Robert Kuster — Fri, 01 Jan 2010 12:52:51 +0100

Hi Will,

first of all I wish you a happy and prosper 2010. May there be lot of www.windbg.info visits and forum posts. As to your questions, there are two things to distinguish:

1) Portable Executable (PE) format (used for EXE, DLL, SYS and OBJ files)

From Wikipedia: "The Portable Executable (PE) format is a file format for executables, object code, and DLLs, used in 32-bit and 64-bit versions of Windows operating systems."

The PE headers and structures are read by the Windows loader (ntdll) - it contains all the information needed to spawn a new process. Note that the PE format hasn't changed over all these years. The most obvious reason is backward compatibility. Say, if Windows 7 wants to execute an EXE written at Windows 98 times the PE format should be the same. Sure, Microsoft added a some new fields to the PE headers over the years. Nevertheless all old fields and data structures of the initial PE format are still the same. In other words you can read any old PE article and rest assured that the information provided there is valid.

Probably you won't often access PE headers during your debugging scenarios directly. But if you want my opinion it is always a good idea to understand what is going on behind the scenes. For instance, did you know that the only difference between an EXE and a DLL file is a single bit in the PE header? So yes, go on and study the available PE articles you mentioned.

One more cite from Wikipedia: "PE is a modified version of the Unix COFF file format."
Few people now days know that in its early days Microsoft had its very own version of the UNIX operation system, called Xenix. This said it is obvious why PE turns out to be a derivative of the Unix COFF file format.

2) Format of debug-symbol files (COFF, CodeView, PDB)

While data stored in the PEs is mainly intended for use by the Windows loader, a debugger actually needs more information to provide human readable information to us. This is where symbol files come in handy. Symbol files help a debugger to map raw addresses in the PE executable to source-code lines, to analyze internal layout and data of applications, and so on. Obviously symbol files are not limited with backward compatibility issues mentioned for PE files above; put it this way: with new compilers there were simply new debuggers made available.

While Microsoft used COFF and later CodeView as their official symbol files in the past, it now days uses the proprietary PDB file format to achieve the same.

It all turns out very simple, doesn't it? :)

Warm Regards, RK

Thread: Can all commands be watched with WinDbg - reply by: Will Steele

Will Steele — Wed, 30 Dec 2009 02:34:08 +0100

Thanks Robert. You've given me a lot to work with. I am still in the "wide-eyed" stage of figuring out very basics. These things help me get a grasp much more quickly.

Thread: Can macros be set up in WinDbg - reply by: Robert Kuster

Robert Kuster — Tue, 29 Dec 2009 21:17:16 +0100

Hi Will, welcome.

Short answer: Yes.

Long answer: WinDbg offers a quite powerful mechanism called "Debugger Commands Programs". In fact this is a simple script-language where you can use all commands available in WinDbg and some additional control flow tokens. With this in mind you can actually write powerful scripts and conveniently store them into files. From within WinDbg you simply call your script-file in question with "$$><" (the human translation of which is "Run Script File").

I briefly covered this topic in WinDbg. From A to Z!; refer to slides 77-80.

For more details you might also check the official Microsoft documentation:
msdn.microsoft.com/en-us/library/cc266360.aspx

I hope this helps.

Warm Regards, RK

Thread: Warmest Welcome to Our Visitors

Robert Kuster — Thu, 17 Dec 2009 22:53:07 +0100

Warmest Welcome to Our Visitors

After I spent quite some time to integrate a Forum solution into our site, I'm happy to announce that it is finally done.

I hope the Forum will serve well for all Your WinDbg related questions and needs.
And I do thank You for any future contributions and posts to the Forum or to www.windbg.info itself.