Welcome to MSDN Blogs Sign in | Join | Help

March 2006 - Posts

Friday, March 31, 2006 4:09 PM

Practical MDAs in MSDN magazine

Stephen Toub writes about MDAs in MSDN Magazine (see here ). Whereas I focuses more on the platform implications , he focus on more practical stuff like: how to enable and disable them; specific MDAs of interest, specific demos to show firing an MDA using
Posted by jmstall | 0 Comments
Friday, March 31, 2006 12:20 AM

Some practice interview questions

Somebody in the comments asked for some practice interview questions for a development position. So here are some general practice interview questions for an entry-level development job in a C/C++ oriented group: 1. Basically any C-style string function
Posted by jmstall | 5 Comments
Filed under:
Tuesday, March 28, 2006 11:11 PM

How did I ever live without it?

Here are some random software things I use that really change how I work. OneNote : Word is not a good way to track general random information such as todo-lists, meeting notes, random thoughts, or anything that you would naturally write in a scratch-pad.
Posted by jmstall | 3 Comments
Filed under:
Monday, March 27, 2006 3:54 PM

Getting answers to questions

I've been getting a lot of individual questions (usually via the contact form) about random things I know very little about. Unfortunately, I can't provide everybody the answers I'd like. Lack of time is one thing. But also, I often just don't know the
Posted by jmstall | 7 Comments
Sunday, March 26, 2006 12:05 PM

Dbg vs. Pdb files

Somebody asked me about .Dbg vs. .Pdb files. Basically, .Dbg files are the predecessor's to .pdb files. For managed code, you're always likely to see .pdb files. That's actually about all I know, but you can find out more here: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q12136
Posted by jmstall | 3 Comments
Friday, March 24, 2006 4:25 PM

Shared Source CLR is available for V2

In case you haven't already heard from every other blogger (like Shawn , JasonZ and Brad ) , V2.0 of the SSCLI (aka Rotor) is now available for download: http://msdn.microsoft.com/net/sscli . I just downloaded it myself. This is basically the source for
Posted by jmstall | 0 Comments
Wednesday, March 22, 2006 9:28 PM

Stop the debuggee to poke at it

In ICorDebug, most operations are only available when the debuggee is stopped. (This was asked here ). Many things will fail with CORDBG_E_PROCESS_NOT_SYNCHRONIZED if you call them when the process is running. The motivation is: 1) Correctness : trying
Posted by jmstall | 2 Comments
Filed under:
Wednesday, March 22, 2006 12:26 PM

The stop count and trivia

ICorDebug maintains a stop-count, and so if you call ICorDebugProcess::Stop() twice in a row, the 1st stop does the real asynchronous-break , and the 2nd stop is basically a nop that just increments a counter. You'll then need to call ICorDebugProcess::Continue()
Posted by jmstall | 4 Comments
Filed under:
Tuesday, March 21, 2006 11:29 PM

Trivia about Set-next-Statement (SetIp)

The poor-man's version of Set-Next-Statement (aka, SetIp) is to just forcibly set the instruction pointer register (eip on x86) to the instruction you want to execute next. However, this naive approach has several problems that ICorDebug's SetIp solves:
Posted by jmstall | 2 Comments
Filed under:
Tuesday, March 21, 2006 12:12 PM

What to expect when you Attach, Async-Break

Don't assume that if you have a thread doing a spin-wait, that you can attach / asynchronously-break ("async-break") and your debugger will immediately stop at the spin-wait. When you attach to a debuggee or async-break while debugging, the debuggee's
Posted by jmstall | 0 Comments
Monday, March 20, 2006 12:38 AM

"Correct" may depend on your point of view

Correctness from the debugger's perspective is very different than correctness from the end-user's perspective. For example, the debugger exposes many invasive operations like SetIp. The debugger considers the operation successful if it sets the IP to
Posted by jmstall | 0 Comments
Saturday, March 18, 2006 10:49 AM

Looking forward to the day when free wireless is just a given

I was bored in SeaTac Airport (my flight got delayed) and so I pulled out my laptop. I wasn't sure what I was going to do with it, but I didn't have any other entertainment options. My brain didn't have the mental energy to be productive, minesweeper
Posted by jmstall | 5 Comments
Filed under:
Thursday, March 16, 2006 4:45 PM

Competing with the docs:

I was reading Charles Petzold's rule " Don't even try to compete with the Docs " and it reminded me of one of the issues I struggle with as a blogger trying to decide what to write about... I find myself in a similar dilemma with blogging. Some people
Posted by jmstall | 0 Comments
Filed under:
Thursday, March 16, 2006 12:09 AM

Put a config file on your debuggers

VisualStudio.Net 2003 has a config file saying that it's for V1.1 CLR. If you write your own V1.1 debugger, you should do that too. One big motivation is to ensure your V1.1 debugger creates the V1.1 implementation of ICorDebug. In V1.1, ICorDebug was
Posted by jmstall | 0 Comments
Filed under:
Tuesday, March 14, 2006 7:27 PM

Why doesn't MDbg use generics?

If you've looked at the MDbg sources, you'll notice it looks a lot like a V1.1 app. There are few to no V2 (Whidbey) concepts in there: few anonymous delegates, very little (if any?) generics, no 'yield' keyword. Since MDbg shipped in V2, why didn't we
Posted by jmstall | 3 Comments
Filed under:
Tuesday, March 14, 2006 11:09 AM

What I'm reading now (Practical .NET2 and C#2)

I've been reading through " Practical .NET2 and C#2 " (by Patrick Smacchia). I finished my previous book (" Why Programs Fail " by Andreas Zeller ) a little while ago. I'm impressed with the book. It's not a C# reference, although it describes new features
Posted by jmstall | 2 Comments
Monday, March 13, 2006 5:44 PM

The JIT does dead-code elimination in Debuggable code

The desktop CLR JIT (at least x86) does dead-code elimination, even in debuggable code. This is obviously perfectly safe, transparent, (and good), from a program-execution perspective. But it can be a little surprising under the debugger because you can't
Posted by jmstall | 0 Comments
Monday, March 13, 2006 12:06 AM

Being a CLR dev does not mean you know everything about the CLR

I find people often assume that just being a developer on the CLR means you somehow know everything about the CLR there is to know. I only wish! First, the CLR is a very large problem space and there's a lot to learn: 5 ECMA partitions. Multiple languages.
Posted by jmstall | 2 Comments
Filed under:
Sunday, March 12, 2006 12:56 PM

Passing env vars to the debuggee

Here are two main ways a debugger can pass an environment variable to the debuggee. 1. Set the var in the debugger process , and then let the debuggee inherit them when its created. This is easy, but dangerous. For example, you should probably restore
Posted by jmstall | 0 Comments
Friday, March 10, 2006 11:06 PM

Chatting about debugging?

If you're at the Microsoft campus at the upcoming compiler-lab and want to chat about ICorDebug or low-level managed-debugging questions, ping us and we'd be glad to swing by the lab during a break and chat. People asked some great debugger questions
Posted by jmstall | 0 Comments
Filed under:
Friday, March 10, 2006 9:16 PM

Is this a good or bad?

Pinvoke.Net is a great site, and I was wondering whether to be happy or sad. On the bright side, it's great to see a community effort like that, and the site is really useful. On the down side, it's sad that pinvoke would be so complicated that something
Posted by jmstall | 4 Comments
Filed under:
Friday, March 10, 2006 12:14 PM

New CLR blogger: Vance Morrison

Vance Morrison , CLR Jit guru, and now Perf -Architect (succeeding Rico ) is blogging . Vance has an amazing wealth of knowledge. He's already written a great entry about how to figure out native codegen for things (such as foreach) and about SOS ; and
Posted by jmstall | 0 Comments
Thursday, March 09, 2006 11:39 AM

Doing Detach with ICorDebug

Detaching a managed-debugger is somewhat complicated at the ICorDebug API level. In a perfectly-friendly API, you could just call "ICorDebugProcess::Detach" and be done with it. With managed-debugging, there are two main constraints and the hresults (in
Posted by jmstall | 1 Comments
Wednesday, March 08, 2006 5:03 PM

Jan is on MSDN TV talking about MDbg

Jan Stranik is on MSDN TV talking about MDbg , the managed-debugging sample written in C#. See the video here . Jan wrote most of MDbg, and handle a lot of hard problems about getting a working debugger in managed code. He gives a brief overview of managed-debugging
Posted by jmstall | 0 Comments
Filed under: ,
Wednesday, March 08, 2006 11:41 AM

MDbg, Managed-debugging, and 64 bit

V2 CLR added support for 64-bit (amd64 and ia64), and that includes managed-debugging support. So a 64-bit MDbg can debug a 64-bit managed app. But what about cross-platform stuff when your debugger and debuggee are different platforms? Here's how MDbg
Posted by jmstall | 2 Comments
Tuesday, March 07, 2006 11:24 AM

"You can't have too much chocolate"

I find it's more difficult to prove things about natural language than about well-defined specified languages (eg, computer languages). Sometimes a good counter-example is the clearest proof of all. A demonstration of your point can be more practical
Posted by jmstall | 8 Comments
Filed under:
Monday, March 06, 2006 1:57 PM

Interview tip: don't diagonalize the Fibonacci sequence

When you're interviewing for a developer position and the first coding question is write up a Fibonacci sequence ("write the body for 'int Fib(int n)'"), your interviewer is probably expecting some 5 line iterative solution that's no worse than O[n].
Posted by jmstall | 14 Comments
Filed under:
Sunday, March 05, 2006 12:44 PM

What does a debugger author need to do to support func-eval?

I've mentioned func-eval (aka property eval) is evil for end-users; but it's also evil if you want to write a debugger that uses func-eval. For example, let's say you're writing your own managed debugger and you have a watch window, and you want to eval
Posted by jmstall | 6 Comments
Thursday, March 02, 2006 11:48 AM

Why don't the managed Debugging APIs expose the Finalizer thread?

That's a fair question. Part of the answer is we don't believe people could use it properly. The main reasons we find people ask are: 1) User curiosity : Users just like to know this sort of trivia when they're debugging. You see 6 threads in the VS threads
Posted by jmstall | 4 Comments
Wednesday, March 01, 2006 9:58 PM

Feedback on debugging optimized (managed) code?

We're looking at ways to improve debugging managed- optimized code (eg, compiled with /o+ ), and would love any feedback. Some specific questions: 1) What's you're biggest pain-point for debugging optimized code? 2) How often do you have to do this? 3)
Posted by jmstall | 11 Comments
Wednesday, March 01, 2006 11:27 AM

Why can't you detach in interop-debugging?

Matt Pietrek noticed you can't detach while interop-debugging (aka " mixed-mode ") in VS. Short answer: this is a limitation of the CLR / ICorDebug. Longer answer follows... Some history : Interop-debugging is managed + native debugging simultaneously
Posted by jmstall | 8 Comments
 
Page view tracker