Purposely corrupting HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009\ value Counter?? RRS feed

  • Question

  • Sounds crazy doesn't it but here my problem.

    Last weekend i had a production system start logging the following exception:




    EventType: PerformanceCounterException 

    TimeStamp: 5/26/2011 10:14:26 PM 

    ExceptionInformation: System.FormatException: Input string was not in a correct format.

       at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)

       at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)

       at System.Int32.Parse(String s, IFormatProvider provider)

       at System.Diagnostics.PerformanceCounterLib.GetStringTable(Boolean isHelp)

       at System.Diagnostics.PerformanceCounterLib.get_NameTable()

       at System.Diagnostics.PerformanceCounterLib.get_CategoryTable()

       at System.Diagnostics.PerformanceCounterLib.CategoryExists(String machine, String category)

       at System.Diagnostics.PerformanceCounterCategory.Exists(String categoryName, String machineName)

       at System.Diagnostics.PerformanceCounterCategory.Exists(String categoryName)



    Now my framework is designed to capture and ignore these errors and disable the performance counter sub system If something like this happens.  But this somehow had the effect of silently crashing my process entirely.  The crash would occur not during initialization but later when the first UDP message entered the process (its a message processing system).  This is .net 2.0 code.  Of course Windows server 2003 neglected to capture a memory dump for me before the problem was resolved.  So now I'm forced with the task of recreation.

    Any ideas how i can put the system in a state where .net would throw a similar exception?

    I have tried editing the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009\Counter programmatically and via regedit no luck.


    For those interested the problem was resolved by running "lodctr /r"

    Friday, June 3, 2011 9:39 PM