Archive
Here comes the Microsoft TechDays 2011
I have the pleasure to announce you that I will speak on two sessions during the next Microsoft TechDays in Paris.
First one will focus on how to find and destroy bugs: “What if Sherlock Homes did debugging ?”.
Second one will highlight major changes in the kernel of new Microsoft operating system: “Kernel changes in Windows 7 and Windows Server 2008 R2”.
I will post the PowerPoint files after the sessions, and a video link if I can find it. Sadly, it will be in French…but I’ll develop on BugSlasher a few things that I learned doing those sessions.
Hope I can see you there!
Memory management under Windows : what your mother didn’t tell you
To cope with the various needs of any kind of software, every operating system offer a generalist memory management system. As it works out-of-the-box most of the time, developers usually don’t dig into it to find how it behaves under the hood. But you may be surprised to know that you can not access all the memory of your process, even when some parts seem to be free. Beyond available memory and fragmentation of user space, there is another barrier that can prevent you to get the remaining free bits : the heap service and the minimum size of a virtual allocation call.
Imagine a software who, after a few hours of uptime, starts to throw out-of-memory exceptions. First thought is that, indeed, you don’t have enough memory left. Let’s say that 1Go is free, and that you just ask for a small block of 30k. If you’re familiar with memory issues, second thought may be: “memory fragmentation! Check the largest contiguous block!”. And if I say that a block of 60k is available ? Well, if you are like me before this issue happens at my work, you’re stuck. But let’s go back to the beginning.
How to always have the local variables values in a .NET callstack
Maybe you already had this kind of details while using the ‘!clrstack‘ command from the SOS debugging extension. And by the rules of the Murphy’s Law, it always happens specifically on the local variable that you really need to see in order to slash the bug you’re working on.
This <no data> stuff can be seen especially in release compilation because the Jitter will use all the optimization tricks it can, among which you can find inlining and massive use of registry for temporary variables, so reading local variables is almost impossible (remember C++ hum ?). Hopefully the CLR offer a simple way to disable any kind of optimization (beware, doing this have a major impact on performances!).
How to break on the ‘Main’ function with the .NET CLR 4.0 and WinDbg
If you ever tried to write a post on a technical blog, maybe you already experienced a strange thing: start with the idea of an article, and ends up with a totally different one. This is definitely the case of this one, as I just tried to have a decent local variable value in a call to the famous “!clrstack” function of the Windbg extension SOS, and I had a lot of trouble trying to break on the main function.
Most internet resources (even the help documentation of SOS itself !) advise the user to subscribe to the CLR load notification, and then load SOS and setup a deferred breakpoint. Well I don’t have any CLR load notification on my computer (Windows 7, and I tried x86/x64 applications targeting 4.0, 3.5 and 2.0), and I remembered experiencing the same behavior on my computer at work. As I’m not the only one having this issue (check this), I decided to write a short post about it.
Finally a simple way to download the “Debugging Tools for Windows”
Since a few weeks (months maybe?) the only way to download the marvelous “Debugging Tools for WIndows” package is something quite difficult : first you have to go to the Microsoft dedicated website, then get the whole Windows SDK package (just a web download starter…) and find which option to install to finally get the Windbg executable. Beyond those annoying steps, Microsoft added another difficulty: the description of each option in the installer is not descriptive at all. And again, publish only an installer for a product that is have been designed to avoid any kind of installation (think about your production server where you really want to use that debugger…) is a little bit weird, isnt’it?
Following the advise of a good friend, I choose to reveal the almost-hidden checkbox and especially give the zipped file of the x86 and x64 version.
x86 and x64 : which version of a debugger should I use ?
Maybe this post will be the shorter ever of this blog, but I have to write something about it. Microsoft offer two version of their Debugging Tools: a x86 version, and a x64 version. Which one do you have to use?
On 32-bit OS, the answer is really simple: you don’t have the choice but to use the x86 version, as the OS will not be able to start a 64-bit executable. End of the decision tree :)
On 64-bits OS, it depends on what you want to debug. Unless you need to dig deep inside the Wow64 layers (and I never had to do that personally, but speaking about it makes me curious about what I can found), just use the x86 version to debug a 32-bits executable, and the x64 version to debug a 64-bits executable. If you mess up with this simple rule, you may encounter serious difficulties to get CLR information through SOS (well, it’s basically not possible as far as I know), have wrong data about common memory structure that Windbg can display, and maybe be unable to load your favorite extension.
How to debug a Windows service
Maybe you thought when you read this title: “well it’s kind of easy, I just have to attach any debugger to my running service“. And you’re definitely right.
But sometimes you have to debug the very beginning of your service (just after the “Start” control), or even before, when the main() function has just started. Or you’re experiencing a bug that happens only with a specific user, or only in a context of a Windows service (could be environment variables, registry keys, etc.). Hopefully, with a few tricks, you can easily setup a debugger that will attach to a process just after its creation.
A symbol server : what is it, and why you should use it
The more complex your information system is, the more you will have bugs, and the more you will have symbol files to manage. The cool thing is that second ones can help you resolve the first ones, read my first post if you are not sure about that. The sad thing is that you could end up with tons of symbol files, and finding the right one for every version of you binaries is just too complicated.
The first key for a successful debug on Windows : the Symbols
I have long pondered about the subject of my first post. Debugging subtle bugs on Windows can be easy or not, but one thing is sure: it is really a pain to understand what happen in a software (at least a native one) without the Symbols. There is lot to say about it, and you can find lots of article on the internet describing the contents and the benefits. My approach will be much more practical: a short description, and why you definitely have to create and use them.
BugSlasher 