A few days ago our testing team asked me how they could collect CPU utilization of our apps and then build cool plots based on that information. My answer was simple "Give me 15 minutes and I'll send you back a simple instruction or snippet". After 3 days of thinking and experiments I understood that I knew absolutely nothing about CPU Time utilization, how to calculate it and what it means. Anyway, I have received quite interesting results and ready to share them.
Data. Data are everywhere. Data were before us. Data will be after us. This story started in one of many usual boring evenings on a usual boring business trip but it unexpectedly transformed into a short but quite exciting research and absolutely not short but interesting walk called Brussels Comic Route. After the story had happened it was almost forgotten but all of a sudden I recalled it as Google violated GDPR and I could not keep it to myself anymore.
Ideal crash dump analysis should be quite straightforward: we open WinDBG, load crashdump, load sos, enter
!PrintException and obtain all information which we need.
And from this prospective we can even use something easier like Visual Studio.
Unfortunately, in real and cruel world this scenario can be complicated with a bunch of legacy code which was written ages ago by developers who thought about things such as quick sell of their product and did not think about anybody who would maintain it in the future.
Second part "2. The Hunt for Loot" is dedicated to revealing some of techniques which can be used against the commonly made mistakes in exception handling, how they can complicate your life and how you can overcome them.
WinDbg is indeed a powerful debugger which is widely known among low-level system developers and is unfairly neglected by more high-level application developers. Although, a well-known Visual Studio Debugger provides both easy and obvious ways to debug your software in the development stage, WinDbg gives much more powerful tools to debug your software in the user environment, when all what you have is just a memory dump of a died program... or some strange things happen in your test lab including your PC. There is a bunch of good books and some blog posts which contain an excessive information on WinDbg usage over the Internet. Unfortunately, a lot of them have a very steep curve (like vi) and due to I could not find any docs which would have made it possible to quickly start to use WinDbg, it was decided to gather my gained experience by means of short practical stories. First part "1. The beginning" is dedicated to some very basic things which you really should do and uncover the most frequent scenario of WinDbg usage: post-mortem debugging.
This post can also be named "Why am I so crazy to start my own blog in 2018?". There are a lot of awesome articles and videos which describe almost everything. And no doubts, there are a lot of cool platforms such as Habr, Medium, CodeProject and other ones with a big community where chances that an article posted there would be read are much higher comparing with having a small blog like this one. A short answer would be "because I want and because I can!". If you want a longer, more descriptive and boring answer you can find it under the teaser. But you should realize that it is something like my own manifesto, so if you do not have a lot of time, have real life or at least your own hobby and do not think about creating your own blog you could skip it without any doubts.