Question: How does the runtime (CLR) decide which flavor of a module to load while profiling? Under what circumstances will it load the profiler-enhanced ngen’ed images? When does it load regular ngen’ed images? Can I use specific profiler event-masks to control the runtime’s behavior? I’m totally confused. Help!
Answer: Pictures speak more than words…………
All the PDC 2008 presentations are now available online. I wanted to quickly share out some of the sessions that I found highly interesting. If you are someone who likes to dig deep under the hood (like me!) then you’ll certainly find these useful.
Coming up in CLR v4
What’s new in Visual Studio 2010?
Some interesting testing tools from Microsoft Research
Open panel discussion on test automation
[Update 11/02/2008] In addition, there was an all-day pre-conference session organized by the performance architects of the .NET framework. The slides are available on Vance Morrison’s blog.
Hope you find these useful.
Our team (the CLR developer services team) makes the debugging and profiling APIs for the CLR. In short, we are responsible for enabling diagnostic tools on the .NET platform. Do you use our APIs in your product? Want to hear about the new features that we are enabling in the next release of the CLR? We’ll be at PDC 2008 and would like to meet up with you.
Also we want to hear about your experience while debugging/profiling on the .NET platform? Have any concerns? Comments? Suggestions? We are all ears. We’d love to hear from you. Your feedback will help us deliver a better product for you.
Where: Los Angeles Convention Center, 1201 S Figueroa St, Los Angeles, CA 90015.
When: Oct 26 - Oct 30.
Who: Our team will be represented by Rick Byers (lead developer), Jon Langdon (program manager) and me.
PDC 2008 site: http://www.microsoftpdc.com
More details to follow ……………………………………
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
Simply hilarious!
On my team, we currently have two open SDET (software development engineer for test) positions that we are actively looking to fill. The job description is already posted here so I’ll not rehash the details.
So what exactly do we do? –
I’ll give you a very high level description. We are a part of the Common Language Runtime (CLR) team and are responsible for producing, testing the debugging and profiling engines. These APIs/engines are consumed by the Visual Studio Debugger, WinDbg and F1 profiler and other ISV tools. As an SDET you’ll be primarily responsible for testing these APIs. This means writing new debuggers/profilers, extending functionality of existing ones, writing automation tools etc.
What we require you to have –
- Interest in low level technologies and bit-twiddling.
- Strong scripting skills.
- Proficiency in debugging (I cannot emphasize this enough!) and fixing bugs.
- 4-6 years of development experience.
- Proficiency in C, C++ and/or any managed language.
Icing on the cake –
- Experience with implementing diagnostic tools like debuggers, profilers or dis-assemblers. Bonus points if they actually work J.
- Knowledge of MSIL and/or native assembly.
- Familiarity with the internals of the CLR – Garbage Collector, Loader, Type System, JIT/CodeGen, Exception handling, BCL, hosting, Security etc.
Please let me know if you (or someone you know) are interested. I encourage you to apply via the Microsoft career website.
Windbg/Ntsd unfortunately does not support a breakpoint hit-counter (I searched through Windbg’s help file but couldn’t find one). It would be very useful to know how many times a particular breakpoint is triggered.
Fortunately for us, we can cook up our own BP hit-counter using pseudo registers. According to the help file, $t0, $t1, …, St19 are available as user-defined pseudo registers. We can use these to store the hit-count.
Bp <module>!<class>::<function> “r $t0 = @$t0 +1; r $t0; g”
Bp <address> “r $t0 = @$t0 +1; r $t0; g”
Please let me know if there is a simpler way to do this.
Struggling with regular expressions? Maybe this might be of some help - http://regexlib.com/CheatSheet.aspx
If you are into writing custom prologs and epilogs for functions with naked calling convention, then you need to -
This is how a function prolog looks like -
__asm
{
push ebp
mov ebp, esp // Set up our base-pointer frame
sub esp, <size of stack variables>
pushad // Save all general purpose registers.
}
So how do you calculate the size required for stack variables? Till date, I used to compute it by hand. Luckily today I discovered the existence of the __LOCAL_SIZE compiler symbol, the value of which is decided by the compiler.
MSDN documentation says -
The compiler determines the value of __LOCAL_SIZE. Its value is the total number of bytes of all user-defined local variables and compiler-generated temporary variables. __LOCAL_SIZE can be used only as an immediate operand; it cannot be used in an expression. You must not change or redefine the value of this symbol.
So now my function prolog simply looks like this –
__asm
{
push ebp
mov ebp, esp // Set up our base-pointer frame
sub esp, __LOCAL_SIZE
pushad // Save all general purpose registers.
}
Quick and easy, huh?
All Windows aficionados are eagerly looking forward to reading the books listed below (I myself haven’t read them yet but these are up there on my list of things to do). Incase you have read them already, let me know how they are -
 |
|
||||||||
 |
|
Image File Execution options provides you with a mechanism to always launch an executable directly under the debugger. This is extremely useful if you ever need to investigate issues in the executable’s startup code (services especially). You can set the IFEO options directly via the registry or indirectly using the Gflags tools (available with the Window debugging toolkit).
You need to create a registry key and populate it with a value as follows -
|
Key |
“HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable>“ |
|
Value |
Debugger : REG_SZ : <full-path to your favorite debugger> |
You do not need the full path to the application, only the exe name will suffice. However you do need the full path to the debugger. As an example, we look at launching notepad under ntsd, you would be creating the following -
|
Key |
“HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe” |
|
Value |
Debugger : REG_SZ : “c:\dbg\ntsd.exe -g” |
You can also use Gflags to set IFEO too -
How does IFEO work?
Kernel32!CreateProcess when called without the DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS creation flags, checks the registry to see if IFEO has been set on the executable that it is launching. If yes, then it simply prepends the debugger path to the executable name, effectively getting the executable to launch under the debugger. If you do not specify the correct path to the debugger, then you’ll probably get greeted with a “file not found” error. In our notepad/ntsd example above, Kernel32!CreateProcess ends up invoking -
“c:\dbg\ntsd.exe -g notepad.exe”
Now ntsd eventually launches notepad under the debugger by calling Kernel32!CreateProcess with one of the following creation flags - DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS. The presence of any of these creation flags forces Kernel32!CreateProcess to bypass IFEO options this time around (else we would have been running into an endless loop) and actually launch the executable under the debugger.
IFEO and 64 bit -
A word of caution - For 32 bit executable running in the WOW on X64 machines, your natural tendency might be to create the registry key in the syswow node -
“HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable>“
However Gregg Miskelly notes that you should set the IFEO corresponding to the bit-ness to the application calling into kernel32!CreateProcess to launch the executable -
“On Win 64, there are two copies of HKEY_LOCAL_MACHINE\Software (one for 32-bit apps, and one for 64-bit apps), and therefore there are two copies of these options. However, where the operating system looks isn’t dependant on the bit-ness of the application that is going to be debugged (which is what you would probably expect). Instead, it is dependant on the bit-ness of the application that called CreateProcess.”
Other IFEO caveats -
Raymond Chen notes the following caveat in his blog entry -
“If you passed special parameters via the STARTUPINFO structure, those parameters get passed to the debugger. And the PROCESS_INFO that is returned by the CreateProcess function describes the debugger, not the process being debugged.”
IFEO and Managed debuggers -
IFEO can only be used for native or interop debugging, but not for managed debugging. Mike Stall has an excellent blog entry that describes in great detail exactly why. The gist is this - Managed debuggers like Mdbg/cordbg/VS.NET use ICorDebug::CreateProcess to launch managed executables under the debugger. However for managed debugging, the debugger should call ICorDebug::CreateProcess without the DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS creation flags (this is publicly documented). This API internally ends up calling Kernel32!CreateProcess without the DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS creation flags. This leads to the endless loop that I described above. Is this an ICorDebug API design flaw? Not really. Just an oversight in my opinion - The API designers missed one scenario. Maybe in the next version of the CLR this will be fixed (I do not know for sure).
Some excellent resources on IFEO -
|
[MSDN] |
Launching the debugger automatically (How to launch VS debugger using IFEO) |
|
Image File Execution options just inserts the debugger in front of the command line |
|
|
Image File Execution Options (talks about the other not-so-well documented IFEO options) |
Exercise for reader -
Does IFEO work with other Win32 APIs like ShellExecute, CreateProcessAsUser, CreateProcessWithLogonW and CreateProcessWithTokenW?
TIP of the day -
Question - System services can launch before the user has a chance to log on. So how do you debug the startup code of these system services?
Answer - Put the machine under kernel Debugger (KD), use IFEO to launch the service under NTSD (use ntsd’s “-d” option to pipe the ntsd output to KD) and reboot the machine. When the system service launches, it will be launched under ntsd. The ntsd debugger will automatically cause it break into KD when it encounters the initial loader breakpoint. The debugging session will begin in user mode automatically (yipee!). After you are done debugging, switch control to KD by issuing “.breakin” command.