Jigar Mehta's Blog : Debugging

Look at the operating system version and SP details from the dump in WinDbg..

Jigar Mehta — Tue, 03 Jun 2008 21:50:50 GMT

This is a very common question, we encounter almost all the times.

Just imagine a situation, we have got a memory dump from somewhere and want to see what operating system which is run there and what SP is installed.. For this, there is a very simple command.

0:001>vertarget

Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
kernel32.dll version: 5.2.3790.4062 (srv03_sp2_gdr.070417-0203)
Debug session time: Tue Oct 30 05:54:21.000 2007 (GMT+5)
System Uptime: 3 days 8:21:53.750
Process Uptime: 0 days 4:28:05.000
Kernel time: 0 days 0:00:34.000
User time: 0 days 0:09:37.000

Stay tuned..

How to change value of register when doing live debugging with Windbg?

Jigar Mehta — Tue, 03 Jun 2008 21:46:11 GMT

Windbg has not only registers reading functionality but it can also modify registers when doing live debugging..

Its really useful sometimes to modify the register values and take different path to check for particular code branch..

You can modify the register value like this..

0:000>r @eax=0x80040005

Above command will modify value of register eax and set it to 0x80040005.

Stay tuned..

What is better way of keeping an eye on last win32 error while debugging?

Jigar Mehta — Thu, 08 May 2008 20:26:33 GMT

I have found it necessary many times to keep an eye on last win32 error, while using Win32 APIs in code! (Calling GetLastError() after each API usage is not feasible solution!).. In Visual Studio they have provided a very good small feature. You can write @err,hr in the watch window,

Similarly, you can use another pseudo register @eax for keeping an eye on the function return value! (If you are looking at some Win32 API's return value, you can also do @eax,hr to find out the text message behind the integer..)

Sometimes these small debugging tips increase significant debugging speed..

Stay tuned..

How can I check the details about Process Token while debugging in Visual Studio?

Jigar Mehta — Thu, 08 May 2008 20:04:44 GMT

Visual Studio 2005 onwards, watch window has got a pseudo register for investigating the details about process token. So, all you have to do is, just start debugging and write "$user" in watch window,

Its interesting to look at expanded view of privileges and groups sometimes!

Stay tuned..

Visual Studio 2005 debugging trick..

Jigar Mehta — Tue, 20 Nov 2007 21:15:14 GMT

Just now, I found a trick in Visual Studio 2005 to debug pointers in better way. You can ',n' in watch window where 'n' is number of elements to display. I think following snapshot is self explanatory..

Stay tuned..

Interesting windbg command-line parameters..

Jigar Mehta — Wed, 07 Nov 2007 16:17:57 GMT

Here is a list of few interesting command-line parameters and their mapping to interactive commands in windbg..

PS: Taken from "Advanced Windows Debugging" (the best debugging book, I have ever come across!!).. Go grab your copy!

Stay tuned..

How to install windbg for post-mortem debugging..

Jigar Mehta — Wed, 07 Nov 2007 16:12:54 GMT

I was looking for a way to install windbg as postmortem debugger so that everytime any process crashes or exits unexpectedly, windbg is launched automatically and I can take a look at whats happening there!

Windbg has special command line option for installing it as postmortem debugger. Use following command,

C:\Program files\Debugging Tools for Windows>windbg.exe -IS

This will set AeDebug entry as,

Path\windbg -p %ld -e %ld -g"

If you want to associate .dmp, .mdmp or .wew extensions with windbg (so that when you double click on them in explorer, windbg gets opened automatically), you can use -IAS option.

PS: command-line option -I is for installing windbg as post-mortem debugger. [S] command line option is optional, if used it will not display any success message after executing the option (silently installation), only error messages are propogated..

Stay tuned..

Extracting modules (EXE, DLL, and other binaries) from memory dump..

Jigar Mehta — Wed, 07 Nov 2007 03:45:52 GMT

Yet another debugging challenge.

Imagine a situation where you get a memory dump from customer and need modules (DLL, EXE, OCX etc.) to further debug.. (.NET modules can be used to look at source code by reverse engineering..)

SOS.dll is at the rescue. We can use clr10\sos.dll inside windbg directory to save all the modules (loaded by target process at the time of taking the memory dump). Interesting fact is, sos.dll can not only extract managed modules, it can also save all the native/unmanaged modules!!

First, load the sos.dll in windbg.

Then use !sam <path> OR !SaveAllModule <path> to extract the modules on specific disk location..

Thats it! Mission accomplished. Though, its not a long process, it can be useful in some scenario..

PS: Later version of sos.dll does not support !sam, you need to manually extract each and every module by providing the loading address.

Stay tuned..

How to debug startup code for a process which is started by some other executable!

Jigar Mehta — Tue, 06 Nov 2007 20:08:54 GMT

Yet another debugging challenge..

The problem is, we want to debug the startup code for an application which is run by some other application! e.g. I will open a console (cmd.exe) which in turn opens calc.exe and I want to debug the initial calc.exe code..

Windbg has solution to this problem! When you select "open an executable", you have a small checkbox saying "Debug child processes also" which actually makes sure that all the processes spawned by parent EXE (which you select in this dialog!) are also attached by debugger.

If you are interested in command line option, '-o' option is at disposal.

Its only this scenario when '|' command is used (at least in user mode)! Because when we attach to any child processes, it shows the current process being debugged in space left to command line in windbg, as shown below!

If you give command | you will be able to see all the processes in list which can be debugged (only one process can be debugged at a time!). You will get output similar to one shown below.

We can also move between different processes by using |<number>s command. e.g. in above example, if we want to go back to debug cmd.exe, we have to give command |0s.

PS: This works only if you are opening (spawning) parent executable.. 'Attach to process' does not have this option of debugging all child processes!

Stay tuned..

How to look at value of structure object who is member of Class object while debugging in WinDbg??

Jigar Mehta — Mon, 29 Oct 2007 05:03:17 GMT

Sometimes when you debug applications, it happens that you have got the pointer to class which has few member variables including structures and another class objects! How to look at values of those inner class/structure variable's members?? So, here is the tip.

Following is the code being used for demonstrating commands.

   1:  struct testStruct

   2:  {

   3:      int i;

   4:      char ch;

   5:      long l;

   6:      char* str;

   7:  };

8:

   9:  class myClass2

  10:  {

  11:  public:

  12:      myClass2();

  13:      ~myClass2();

  14:      testStruct structObj;

  15:  };

16:

  17:  myClass2::myClass2()

  18:  {

  19:      //Do Nothing..

  20:      char *pStr = new char[100];

  21:      sprintf(pStr, "Test Message");

  22:      structObj.i = 101; structObj.l = 1001; structObj.ch = 'j'; structObj.str = pStr;

  23:  }

24:

  25:  myClass2::~myClass2()

  26:  {

  27:      delete structObj.str;

  28:  }

29:

  30:  int test2(myClass2* classObject)

  31:  {

  32:      return classObject->structObj.i;

  33:  }

34:

  35:  void CWinDbgDlg::OnBnClickedButton2()

  36:  {

  37:      // TODO: Add your control notification handler code here

  38:      myClass2 *ptr = new myClass2();

  39:      int retVal = test2(ptr);

  40:  }

So, what we want to do is, while we break @ test2 function, we want to see in WinDbg whats the value of structObj.str of that instance.

Here are steps which needs to be done in Windbg. Attach the process to WinDbg, break on the function test2 by putting simple breakpoint. Hit kb command to find out the first parameter to test2 function (which is pointer to class object for myClass2).

First parameter to function test2 is, 0x006ab520 (see the third column in first row of call stack above). As you might know, if you want to see member variable of class object pointer, you can use dt command.

But, our goal is to find out whats inside structObj! Well, you can give following command to get that detail,

Notice the difference between last command and one prior to that. We appended "structObj." at the end. That's how we can find members inside that structure. Mission Accomplished!!

I know, its really difficult to explain what exactly we are doing, and I think I am trying my best to explain it with the help of snapshot and coding, if you think it can be improved, please let me know..

Stay tuned..

How to break in WinDbg when particular function returns specific value??

Jigar Mehta — Mon, 29 Oct 2007 03:09:03 GMT

If you are debugging a lot, you might come across a need where you need to put a breakpoint on a function and special requirement is you need to break only when that function returns a specific value!! e.g. I am checking for CoCreateInstance method from COM library and want to break only when it returns 0x80040154 (i.e. Class Not Registered!). Obviously, we can put normal breakpoint by using following command,

bp Ole32!CoCreateInstance

but it will break everytime that function will be called, say if you have 3000 COM component instances created in your code, you will loose some of your hairs reaching interest of your break in WinDbg.

So, here is the technique to the rescue. I will first explain the logic how its done.

Little background, In Windbg, we can put conditional breakpoints where we can check register values (like eax, ebx, eip, esp etc.) when particular breakpoint is hit. Conditional breakpoints will break only if condition is satisfied.
If we can get the return address for our function of interest, we can put breakpoint on that address checking for eax register value (return value is always stored in eax register when function returns). And that way, we can break while returning the function if particular value is set in eax register.

Here is a sample example.. What we need to do is, we want to break in WinDbg only when myClass::test1 returns 100 otherwise go ahead.

   1:  class myClass

   2:  {

   3:  public:

   4:      myClass();

   5:      int test1(int param1);

   6:      void Crash();

   7:  };

8:

   9:  myClass::myClass()

  10:  {

  11:      //DO Nothing.. let runtime construct the object..

  12:  }

13:

  14:  int myClass::test1(int param1)

  15:  {

  16:      return param1 * 2;

  17:  }

18:

  19:  void myClass::Crash()

  20:  {

  21:      int another_var=0;

  22:      int p = 200/another_var;

  23:  }

24:

  25:  void CWinDbgDlg::OnBnClickedButton1()

  26:  {

  27:      // TODO: Add your control notification handler code here

  28:      myClass *obj = new myClass();

  29:      int retVal = obj->test1(50);

  30:      if(retVal == 100)

  31:      {

  32:          //Some faulty condition has occurred, you dont want to come here,

  33:          //catch this condition before this happens (in debugger)..

  34:          obj->Crash();

  35:      }

  36:  }

I am debugging above code. Following are few things that should be carried out in WinDbg. Attach to the process you want to debug.

Find out the address of function (not the return address) you are interested in.

Put a breakpoint on that function (this is just to find out return address of the function.. If you can findout return address by some other technique let me know!)

Hit 'g' and execute application till it calls this function. When it breaks for that function, give k* command to see call stack, as it will show the return address in function call stack!

Here, 0x00412e93 is the return address we are interested in! So, put the conditional breakpoint as follows,

bp 00412e93 "j @eax = 0x00000064  '';'gc'"

Notice here one thing? Yes, you are right. We are putting breakpoint for eax register while checking for value 0x00000064 which is Hex equivallent of 100 decimal (dont forget this step, otherwise you will never hit the breakpoint!)

After doing above, hit 'g' and you will break only when test1 function returns 100. (In my case, it will break immediately because I have hardcoded the parameter 50).

Stay tuned..

Looking at commands supported by WinDbg extensions..

Jigar Mehta — Mon, 29 Oct 2007 02:15:14 GMT

If you want to look at commands supported by any windbg extensions, you can follow various ways.

You can use !<ext_name>.help command to see all the commands supported by that extension. Replace <ext_name> with your extension module name. (Note: This will only work if particular extension supports help command.)
You can open the extension DLL in Dependency Walker and it will show all the command in exported function panel! There is no magic behind it, its merely a fact that WinDbg has very simple extension model, where you need to implement exported function for each command. Windbg just does GetProcAddress for that function and call into that, when we use that debugger extension command in Windbg. And dependency walker has functionality to show exported function from a module.

Stay tuned..

How to attach WinDbg to a service?

Jigar Mehta — Sat, 27 Oct 2007 06:19:19 GMT

There are various ways to do this.

Find the PID for process that is hosting the service. You can do this with the help of command,
tasklist /svc

Look for service and associated PID, then go to command prompt, into the directory where windbg is installed and give command,
windbg.exe -p <ProcessID>
Another way is to directly use the service name as parameter to windbg. This is more convenient way, but hardly known to users/developers. You can use following command,

windbg.exe -psn RPCSS

Above command will find out the process which is hosting RPCSS process and then attach the debugger to that process.

Stay tuned..

Loading/reloading symbols for just one module..

Jigar Mehta — Fri, 26 Oct 2007 02:18:49 GMT

Many a times it happens that from within a debugging session, we need to load / reload symbols for a particular module (Talking in context of WinDbg).. e.g. we started debugging, set normal symbol path and down the line while debugging, came to know that we need symbol for particular module. We modify symbol file path. If we do,

.reload /f

it loads all symbols again from the same location which might take time.

So, just managed to find the command to load just one particular module's symbols,

.reload /f @"mydll.dll"

This will load symbols for mydll.dll using latest symbol path.

Stay tuned..

Notepad hangs while saving the file

Jigar Mehta — Thu, 17 May 2007 03:52:53 GMT

From last few days, I have been experiencing very strange problem.

Problem: When I create a new file in Notepad.exe and click on File+Save or alt+s, it literally hangs when showing the dialog (save dialog to give file name/path). If I wait for more than 2 minutes, it comes out of the hang state and shows me the dialog.

Troubleshooting: I ran procmon (http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx) and saw that notepad.exe was trying to reach "\\jigarm\" machine name. Analysing more, I found that it was there in the Recent History list. Now, the situation is, I had a machine named "jigarm", now I had to format it and new machine name is, "jigarme" So, everytime, I try to save the file, it loads the most recent path and just because "jigarm" does not exist, network access API call, just waits for timeout. (Windows Vista has significant improvement on these kind of hanging kernel calls!)

Resolution: I opened regcrawler (http://www.dcsoft.com/products/regeditx/regcrawler.htm) and searched for all references to "\\jigarm" in whole registry, I found not only notepad.exe but other processes like, windbg.exe and winword.exe having reference to that network machine name in recent save locations.

Stay tuned..