Visual Studio debuger visualizer for JsonCPP

6 06 2015

We’ve been working with the JsonCPP library and while it’s very nice to use, it’s a bit of a pain to debug. For example consider this simple JSON value:

var json = [ 
    "name": "hello", 
    "pi": 3.1415926, 
    "valid": true 

If you want to see the value of the pi in the debugger it would look (after some digging) something like this:

JSON with no visualizer

After enduring this for a bit too long I decided to look for a debuger visualizer for JsonCPP but couldn’t find one. So as a last resort I decided to write one myself. I have to say that I was pleasantly surprised to find that this was pretty simple and after a little work I got to the situation that my debugger window looked much more manageable:

JSON with visualizerIf you want to use this visualizer you can find it at in GitHub’s visualstudio-debugger repository.


Who touched my files?

16 08 2012

When the three bears got back to their lodge they were eager to find out who touched all their stuff. We were recently in a similar position, our application was too slow, we suspected that we were accessing the file system too much and wanted to find out who was to blame. A short ProcMon session showed we were right but even with the view stack functionality it was a bit difficult to understand what each file access was doing and whether it was justified.

We wanted a breakpoint that will fire every time a file is read whether it’s from .NET or native C++ code and the following breakpoint fit the bill.

When reading a file you must first get a file handle which is done with the Win32 CreateFile function, since all current versions of Windows use wide characters for strings CreateFile  is a macro that points at the CreateFileW function. As you can see from the documentation this function accepts 7 arguments each is 4 bytes big meaning that a total of 28 bytes are passed to it. Because Win32 functions use the __stdcall calling convention the symbol for this function is preceded by an underscore and followed by an at sign followed by the number of bytes passed on the stack.

Hence break at function: _CreateFileW@28

Now in order to break only when accessing files that concern us we add a condition. Look at the first parameter (lpFileName) which is at location esp+4  (right after the stack pointer) and treat it as a wchar_t*. Now call the wcsstr function from the C runtime to see if our file is being accessed (it will return nullptr if the substring isn’t found).

Hence condition:

wcsstr(*(wchar_t**)(esp+4), L"porridge")

I hope others find this breakpoint as useful as I did.

You know it’s time for a coffee break…

19 12 2010

You know it’s time for a coffee break when your breakpoint window looks like this.

For those of you who are (like me) not used to debugging low level code that often _TlsGetValue@4 means that TlsGetValue is an __stdcall function that has 4 bytes worth of arguments placed on the stack. The conditional part of the checkpoint looks after the stack pointer (the ESP register) to get the value of the first argument and I’m not entirely sure what the ==71 part does…