Debugging

Clearcase MVFS corrupts file – Cannot delete file “Invalid DOS Function”

Posted on June 30, 2009. Filed under: Debugging, Woes |

I have clearcase 7.0.1.2 on Win2k OS.
When I built a project using Visual Studio .NET 2003, files are created in output “Release” directory which gets created under the vob. In this folder one particular file “vc70.idb” started creating problems. During further builds, VS is not able to delete this file to overwrite. My first reaction was to delete it from explorer only to find “Invalid DOS function” or such similar error message. Next step was to open CMD and try to delete this file. This too gave the same useless error message.  Due to urgency, I renamed the “Release” to “Release_somenumber”, changed output directory to my local drive and did further builds.

I got back to the problem later and there was no other way to delete this vc70.idb file. Name shows up in the explorer but just cannot get rid of these files. Our IT support guys were told about the problem and they came down, struggled for few hours and finally left saying they will escalate to IBM team. I did not wait for them because I know they will take few weeks to solve this.

So I decided to solve this myself with ever useful sysinternals tools. Solving this issue was trivial.

1. I fired up filemon.exe from sysinternals.
2. I opened explorer and tried deleting this “vc70.idb” file.
3. Stopped filemon capturing. Filemon shows the actual file location vc70.idb points to in the clearcase view. It leads to something like
“\\networkshare\csv_view.vws\.s0018\80000eabbglslvc70.idb”
4. Now it is trivial: open notepad and save the file with the same name shown by filemon in that location.
5. Go to explorer and simply delete the file!! voila!!

Read Full Post | Make a Comment ( 2 so far )

WinDbg internal release with CLR support

Posted on December 11, 2008. Filed under: Debugging, Tools | Tags: |

As explained by Volker von Einem here, WinDbg 6.70.05.0 is special in the sense it has CLR debugging support. Microsoft erred and released this version which is actually internal release. It is not available for download anymore and those who have kept copies are lucky. Worst still, MS never intends to release this CLR support in the foreseeable future.

Just in case if you are that unlucky one and have not got 6.70.05.0 version with you, I digged out a link which seems to work:

hxxp://cert.sjtu.edu.cn/download/mdt/dbg_x86_6.7.05.0.exe

I need to get MD5 hash from Volker since he has original one from MS. I’ll then update this post just to make sure Chinese website has not modified it in anyway.

Read Full Post | Make a Comment ( 11 so far )

Storing your Debug Symbols

Posted on December 2, 2008. Filed under: Debugging | Tags: , |

Here is simple batch file to store symbols of released versions of your product. Symstore.exe is used from Debugging Tools. I use this regularly to save debugging symbols of our product locally in structured manner.

set BUILDNUM=%1

“C:\Program Files\Debugging Tools for Windows\symstore.exe” add /r /f “<path-to-your-prod-symbols-in-the-build>\*.pdb” /s \\<path-to-symbol-store-folder> /t “My Product Name” /v “Build %BUILDNUM%”

Developers can then append path to existing symbols path:

SRV*C:\WinSymbols*http://msdl.microsoft.com/download/symbols;<path-to-your-symbol-store-folder>

If some product is buggy and you don’t want symbols of it anymore, you can use Symstore to remove by using ID. This ID can be found in “<path-to-your-symbol-store-folder>00Admin” folder.  “History.txt” in this location will also show the date when storing is done and corresponding ID.

Advantage using symstore is, needless to say, you don’t have to worry about looking for right symbols when debugging your product. WinDbg resolves it for you 🙂

Read Full Post | Make a Comment ( None so far )

WinDbg New Release 6.10.3.233

Posted on November 23, 2008. Filed under: Debugging | Tags: |

WHDC site announced new WinDbg release 6.10.3.233

http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.10.3.233.msi

Read Full Post | Make a Comment ( 4 so far )

IGroupPolicyObject::New will fail if thread is impersonating or identity or delegation

Posted on November 18, 2008. Filed under: Debugging, Woes | Tags: , |

I had the chance to debug into CGroupPolicyObject::New method in GPEdit.dll since the call is failing.

My finding is that if a thread’s Security Impersonation Level is anything other than Anonymous, the call will fail.

SecurityAnonymous, SecurityIdentification,
  SecurityImpersonation,
  SecurityDelegation

The reason is that the code in this method is as follows ( this is my code guessed from disassembly):

HTOKEN hToken = NULL;

OpenThreadToken(GetCurrentThread(),TOKEN_DUPLICATE,TRUE,&hToken);

CGroupPolicyObject::EnableSecurityPriv();

SetThreadToken(0,hToken);

You see, they are opening the token without TOKEN_IMPERSONATE flag and SetThreadToken will throw error if this flas is not used in the access token. Reason why it works for anonymous level is OpenThreadToken fails and sets hToken to NULL. And the resulting call is SetThreadToken(0,NULL) which will succeed. See SetThreadToken() in MSDN.

Tool used: WinDbg

Read Full Post | Make a Comment ( 5 so far )

Before you trace or sneeze…

Posted on August 4, 2008. Filed under: Debugging |

Before doing any kind of tracing, especially tracing combined with ‘z’ command in WinDbg, make sure you have .step_filter set appropriately. Otherwise the debugger will not give chance to debug since with every step all open dbg windows have to be updated and you don’t want to end up tracing deep inside core dlls like NTDLL, MFC etc. See the cartoon Igor’s mistake .

Read Full Post | Make a Comment ( None so far )

Dr. Debugalov cartoon marathon slow down…

Posted on July 20, 2008. Filed under: bugs, cartoons, Debugging |

It was a marathon. A week of Dr. Debugalov’s debugging tales’ cartoons has ended. My free time last week is over and I’ll be developing and debugging in a new project. It does not mean there will be no more cartoons 🙂 I’ll more or less sketch a cartoon-a-day.

It is little time-consuming to scan and transfer pencil drawing to digital form and work on it. I’m still struggling with GIMP and Artweaver (both are excellent freeware raster graphics programs). Smoothness of pencil drawing is lost (due to grayscale pixels) when scanned and that is the main problem for me.

Read Full Post | Make a Comment ( 4 so far )

Dr. Dmitry Debugalov series

Posted on July 14, 2008. Filed under: cartoons, Debugging | Tags: |

I’m happy to announce that debugging patterns guru Dmitry Vostokov has accepted my cartoons for his site Dump Analysis

You can see these cartoons at the Arts & Photography section of Dump Analysis site. In the series, Dmitry goes by the name Dr. Dmitry Debugalov and he demonstrates unusual ways of unearthing bugs and analyzing various debugging conundrums.

The series will grow organically until Dr. Debugalov runs out of disk space or the space runs out of dark matter and collapses. so keep a watch on it.

Read Full Post | Make a Comment ( None so far )

Read MSDN carefully

Posted on June 30, 2008. Filed under: Debugging |

John Robbins had warned about this in his debug war stories: read MSDN carefully.
We missed this and ended up with crash.

Details:
MSDN says "GetDlgItem() returns pointer which is temporary and should not be saved and used later." Well this remark didn’t catch the eye because we anyway use the pointer in the same method and never save it.

So, naturally, we ignored this and did what it warned against. We got pointer to dialog control. Before using it though, of course in the same method,
we did some calls which invoked COM objects. After this we used the CWnd* pointer to enable the window and !BOOOOM!.. WER flashed.
Invocation of this COM object somewhere deep down has overwritten memory pointed by CWnd* returned by GetDlgItem(). Solution was to call GetDlgItem() and use the pointer immediately.

Read Full Post | Make a Comment ( 2 so far )

Crash dumps in Vista – enforce

Posted on June 6, 2008. Filed under: Debugging, Tips or Trix Dept. |

I picked up this tidbit from Mark’s Blog. Windows Error Reporting in Vista doesn’t create dump for all crashes except for some. Here is a way to configure it to create dumps in Vista SP1 as said by Mark:

“… take advantage of Vista SP1’s “local dumps” functionality so that I’ll automatically get a crash dump to investigate for any application crash I experience. If you create a key named HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps, WerFault will always save a dump. Crashes go by default into                     %LOCALAPPDATA%\Crashdumps, but you can override that with a Registry value and also specify a limit on the number of crashes WerFault will keep.”

Read Full Post | Make a Comment ( None so far )

« Previous Entries

Liked it here?
Why not try sites on the blogroll...