Welcome to MSDN Blogs Sign in | Join | Help

July 2006 - Posts

Lessons from political bloggers

Today on MS Campus, two successful political bloggers, conservative Stefan Sharkansky and liberal David Goldstein , spoke about blogging. They had a lot of similarities: Both software entrepreneurs, 43, sporting beards, transplants to Seattle, parents
Posted by jmstall | 0 Comments
Filed under:

Upcoming compiler lab

There's an upcoming Lang.Net Symposium (Compiler Lab++) on Microsoft Campus. Kathy and Thottam have more details. The schedule's got a lot of stuff that's sounds a lot cooler than debugging; but if you're on campus and want to chat about making your language
Posted by jmstall | 0 Comments
Filed under:

MDbg / ICorDebug forum is now available!

We've just created a new public forum for answering ICorDebug and MDbg questions. Check out: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=868&SiteID=1 This is a great place to post any questions you have about the Mdbg sample, ICorDebug,
Posted by jmstall | 0 Comments

Caveats about managed JIT-debugging

I received some questions in the mailbag about what Debugger.Launch actually does. Debugger.Launch the same mechanism as JIT-attach when you get an unhandled managed exception. Here are some random caveats about the jit-launch mechanism: Jit-launch calls
Posted by jmstall | 3 Comments
Filed under:

Resolving functions and func-eval syntax

I got a question about MDbg's func-eval syntax, which brings up a nice point about function resolution: Is it possible to evaluate a function by specifying an instance variable instead of the fully qualified name of the class? f ex.get_StackTrace ...

You can't cast from a pointer to a managed object in the debugger

During native debugging, it's common to cast a raw pointer value to a given type. Eg, in the expression window, do: (Foo*) 0x12345; You may have noticed that you can't do this in managed code. This is a restriction at the ICorDebug (CLR) level. Some of
Posted by jmstall | 2 Comments
Filed under:

Coffee and the L2 Cache

My wife gave me a coffee grinder for my birthday. I've come a long way from instant coffee; I've now got the whole coffee pipeline: from whole beans, through the grinder, through the coffee maker, into the coffee pot, and into my mug. Anyway, thinking
Posted by jmstall | 6 Comments
Filed under:

#line hidden vs. DebuggerNonUserCode attribute

I got this great question from the mailbag: "[W]hat is the relation between the "# line hidden" directive and the DebuggerNonUserCode attribute ? Are these the same ?" Short Answer : They're both markings that library authors can put in their source code
Posted by jmstall | 1 Comments
Filed under:

Experiences with FxCop and wrapping the native debug API

I'm writing some managed wrappers for the native-debugging API (I expect they'll eventually become part of the MDbg sample). I'm trying to make them FxCop compliant. Here are some random thoughts about my experiences. FxCop has a lot of great rules. Merely
Posted by jmstall | 6 Comments
Filed under:

Conventions for passing the arguments to a process

A process's main() function gets an array of strings for the command line args. This is string[] in C#, or {int argc, char** argv} in C/C++. But there are some different conventions for how the parent app passes those strings in. If you execute a program
Posted by jmstall | 4 Comments
Filed under:

Working on managed wrappers for Native Debugging API

FWIW, I've been working on some managed wrappers for the native debugging API ( kernel32!WaitForDebugEvent ,etc) My goals are: Make it extremely easy to use the native debugging API. Maintain fidelity to the native debug API. I didn’t want a super thick
Posted by jmstall | 12 Comments
Filed under:

Managed vs. Native debugging APIs

FxCop has a great rule ( UseManagedEquivalentsOfWin32Api ) to tell you about managed APIs that exist instead of trying to pinvoke out. I'm writing a native debugger in managed code (more on this later), and FxCop was telling me to use the managed debugging
Posted by jmstall | 6 Comments

Debugger.Log vs. OutputDebugString

Both Debugger.Log and OutputDebugString have some key similarities: The both log string for debugging purposes Both have thread-affinity. (The debugger can find out which thread logged) Data is piped through with no additional semantics in the debugger
Posted by jmstall | 3 Comments
Filed under:
 
Page view tracker