Friday, March 1, 2013

So what’s this IntelliTrace thing all about?

Just read through an excellent series on IntelliTrace over at The Ultimate Visual Studio Tips and Tricks blog. It’s a 4 part series that explores the rationale behind a product like IntelliTrace and describes how it can be used.

Noteworthy Points

  • It used to be called “Historical Debugging”
  • It introduces some restrictions on Edit and Continue if you enable call tracing.
  • It has to be on when the process being traced is started. This is because it injects code when a process’s MSIL is JIT-ed into native instructions. This only happens once: the first time a block of code executed.
  • It’s a .net 2.0+ thing supporting C# and VB.net apps. Once again, sorry C++!
  • It’s pretty much the only way to debug Windows Azure apps.
  • It can be used in IIS via powershell, VS Test Manager, SharePoint.

Observations

The Events tracking reminds me a lot of process monitoring tools in SysInternals. Events of interest are operations that tend to be sources of error:

  • opening the wrong file.
  • writing the wrong value to a registry key.
  • binding the wrong parameter to a sql command.
  • parsing xml files that have errors in them.
  • et cetera…

There are many ways to write code to do any one of these operations. IntelliTrace comes with a predefined list that covers most (if not all). That is, IntelliTrace synthesizes all of the ways to open a file (by path string, by FileStream, etc…) into the concept of an Event (opening a file) and identifies every point in the execution of a program that a file was opened.

In this way IntelliTrace strikes me as operating at a higher level of abstraction than traditional (or live in the parlance of the series) debugging. Traditional debugging is about the call stack, locals, watches and breakpoints. IntelliTrace Events is temporally oriented and is all about groups of operations that tend to be sources of execution errors.

Logic Errors, where a program doesn’t exhibit faulting behavior (e.g., reading a file that doesn’t exist) but does not behave as intended, require the much more heavyweight (with respect to performance impact) IntelliTrace Calls tracing. Calls and their parameters are traced. IntelliTrace provides some filters to weed out sources of noise (e.g., system calls) but for debugging Logic Errors the onus is on the developer, who has knowledge of how the program should behave, to identify the source of an error.

No comments :

Post a Comment