October, 2008

  • Never doubt thy debugger

    How to automate Process Monitor


    The other day I needed to capture a Process Monitor trace on a machine to troubleshoot a problem where the entire OS GUI was “broken” after the resume from screensaver; with “GUI broken” I mean that clicking on any icon on the desktop has no effect, the right click menu does not work etc…, but we are still able to access the Task Manager and run tasks (command line etc…) from the File > New Task (Run…) menu. This suggests the user’s registry is for some reason unloaded during when the screensaver is running, but the point is: if I run Procmon before the screensaver starts and wait for the problem to reproduce (to have a complete trace) then I’m unable to save the trace because I cannot access any running task which a GUI unless I start a new one or reboot the machine. Either way the trace is lost.

    Coincidentally also my colleague Stefano had a similar problem and we (he, actually) found a couple of command line switches that can be used to control Procmon for such situations, in particular “/BackingFile” and “/Terminate”: /backingfile tells Procmon where to automatically save the trace, while /terminate actually starts a new instance of Procmon, terminates all other Procmon instances and exits.

    So now I can start Procmon like:

    procmon /quiet /minimized /backingfile c:\temp\trace.pml

    before the screensaver starts, wait for the problem to reproduce, resume the OS and even without access to the GUI and from the Task Manager run:

    procmon /terminate

    Now I can safely reboot the machine and have my trace to analyze; of course you can also use those (and other) command line switches in a batch file or scripts if you need to automate the tool.



    Quote of the day:
    The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. - John Cage
  • Never doubt thy debugger

    HashTable insert failed. Load factor too high


    I already encountered a few recurrences of this errors and every time it has been a torture to capture a correct set of data (especially memory dumps) to review because this usually happens sporadically and you could have to wait weeks if not months before getting it again. There are a couple of hotfix available for this error message (see http://support.microsoft.com/default.aspx?scid=kb;EN-US;831730 and http://support.microsoft.com/default.aspx?scid=kb;EN-US;893314) but you already have them if you’re on the latest Service Pack for the .NET Framework.

    Unless you’re using HashTable objects yourself… If that’s the case you might be running into a race condition which leads to the error, so you might want to consider to use the following code to synchronize the HashTable using SyncLock:

    Dim MyHashTable as new Hashtable()
    SyncLock MyHashtable.Syncroot
    MyHashtable.Add (myKey, myValue)
    End SyncLock

    As an alternative you can use the Hashtable.Synchronized() method to return a synchronized (thread-safe) wrapper for the HashTable object.



    Quote of the day:
    Everyone is a genius at least once a year. The real geniuses simply have their bright ideas closer together. - Georg Christoph Lichtenberg
Page 1 of 1 (2 items)