{"id":2656,"date":"2008-08-12T04:57:00","date_gmt":"2008-08-12T04:57:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/man-eats-crow-film-at-eleven\/"},"modified":"2016-07-28T10:49:20","modified_gmt":"2016-07-28T10:49:20","slug":"man-eats-crow-film-at-eleven","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/blogs\/man-eats-crow-film-at-eleven\/","title":{"rendered":"Man eats crow, film at eleven"},"content":{"rendered":"

Last week I’d had a bit of a rant here about not using software for anything other than what it is designed to do. Thinking back, though, I have done this quite a few times myself, particularly by employing a code profiler to do the job of a debugger.<\/p>\n

When good software goes bad, the right axe to wield at it is usually a debugger. Anyone who has used a debugger will probably tell you that this is a last resort, though, unless they are masochists who enjoy inflicting mental anguish on themselves. Even with the whizzy .NET runtime environment we have now, trying to find the cause of a crash or hang using a debugger requires quite a lot of patience, skill, and experience.<\/p>\n

Yesterday, I had to try to diagnose a program hang – not my favorite thing in the world. So off I went as I have done squillions of times, using the old auto-dumper from Microsoft to get a dump file for analysis:<\/p>\n

cscript adplus.vbs -hang -pn MyFlakyProgram.exe<\/p>\n

Only this time, the debugger died before reaching the critical part of the code, making a dump too early and detatching from MyFlakyProgram. What now? Debug the debugger?<\/p>\n

It was time to rummage through the old toolbox and see what else I could do. I have a code profiler — sure, why not? I had attached a code profiler to the flaky application, got to the critical bit, and took a snapshot. Then another. It seemed that the application had been running a SqlDataReader.Close() method for about 214 seconds by then, which sounds about as far from normal as Timbuktu is from where I’m sitting.<\/p>\n

Honestly, I still haven’t worked out why<\/em> this had happened yet, but I am that critical one step closer, no thanks to the CDB debugger that crashed out on me.<\/p>\n

The other time I had used a code profiler in an unorthodox way was to try to figure out why an application was crashing with a TypeInitializationException. Again, this happened too quickly to have time to attach a debugger (yes, I know about the ImageFileExecutionOptions registry key, but haven’t you figured out how unapologetically lazy I am yet?).<\/p>\n

TypeInitializationExceptions are thrown when an application is first being loaded into the .NET runtime, so there is no possibility to get a stack trace when the program bombs. You’ll never, ever figure out what has happened without some sort of Intermediate Language X-Ray machine, which is sort-of what a code profiler does.<\/p>\n

The profiler also shows the method results in more-or-less chronological order, so maybe, just maybe, I could work out what the last method executed by the errant program had been. And as by a crepuscular ray of light<\/a>, the answer was illuminated — someone had put a method that enumerates printers inside a type initializer (the bit of a class where variables are declared and have their initial values set). Here was the culprit:<\/p>\n<\/p>\n

internal class MyForm : System.Windows.Forms.Form <\/p>\n

{…<\/p>\n

private<\/p>\n

static bool s_HavePrinters = PrinterSettings.InstalledPrinters.Count > 0; <\/p>\n

As fate would have it, this code doesn’t work so well when your Print Spooler<\/strong> service is stopped!<\/p>\n

.NET managed code profilers are designed to show where performace problems may exist in applications by measuring the time taken to enter and exit a method in the code. They could also, however, be leveraged as a powerful potential fault-finding tool. I wouldn’t absolutely depend on one for this purpose, but it’s nice to have a backup troubleshooting method when my debugger is on the fritz.<\/p>\n","protected":false},"excerpt":{"rendered":"

Last week I’d had a bit of a rant here about not using software for anything other than what it is designed to do. Thinking back, though, I have done this quite a few times myself, particularly by employing a code profiler to do the job of a debugger. When good software goes bad, the right……<\/p>\n","protected":false},"author":27149,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[],"coauthors":[],"class_list":["post-2656","post","type-post","status-publish","format-standard","hentry","category-blogs"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/2656","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/27149"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=2656"}],"version-history":[{"count":2,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/2656\/revisions"}],"predecessor-version":[{"id":41649,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/2656\/revisions\/41649"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=2656"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=2656"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=2656"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=2656"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}