Today I have a pleasure to present you my first WinDbg extension lld 🙂 For now it contains only one command: !injectdll, which allows you to inject a DLL into the process being debugged. There is a similar command in the sdbgext extension, but it works only for 32-bit processes. The usage is extremly simple – just remember to load the extension in the correct bitness (32-bit version for 32-bit processes). Example session may look as follows:
0:000> .load lld
0:000> !injectdll c:\temp\Test.exe
ModLoad: 00000001`3f820000 00000001`3f924000 c:\temp\Test.exe
ModLoad: 000007fe`fd960000 000007fe`fd98e000 C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`ff410000 000007fe`ff519000 C:\Windows\system32\MSCTF.dll
(bac.5a0): Break instruction exception - code 80000003 (first chance)
00000000`778c7800 cc int 3
The binaries can be found under the release tab of the source code repository.
Today’s short post was inspired by a recent memory leak in Nancy. I thought it’s worth to describe it in detail as the reason why the memory was leaking was not so obvious and many of us could commit the same mistake as Nancy authors. The leak was present in the
NancyEngine class, which is the central point in the Nancy request handling process. In other words: each request served by the Nancy application must pass through this class instance.
NancyEngine processes the requests asynchronously and accepts as a parameter a
CancellationToken instance – thus making it possible to cancel the request from the “outside”. At the same time it uses an internal
CancellationTokenSource instance which cancels the current requests when the engine is getting disposed. As you see there are two cancellation tokens involved and the
HandleRequest method needs to respect their statuses. For such an occasion there is a method in the
CancellationTokenSource class in .NET Framework which creates for you a special “linked”
CancellationTokenSource that will depend on values in the related tokens. From now on you don’t need to worry about the other tokens as whenever they get cancelled your linked token will become cancelled too. With this introduction the prologue of the
HandleRequest becomes clear:
In this short post I would like to present you am interesting fact about app_offline.htm. Let’s start with a small puzzle. Imagine you have 2 files in your IIS application folder: web.config and app_offline.htm. Web.config contains following lines:
We'll be back in a moment.
Notice that in the web.config file the configuration tag is not closed. Now the question is: what will you see if you try to access your application from the browser?
After Microsoft has rolled out a stable version of Windows 8.1 I wanted to have it installed on all my computers. The update went smoothly on my home desktop and a tablet but I had problems on a PC at work – the Store application could not connect to the Internet and I kept getting an error message: We weren’t able to connect to the Store. This might have happened because of a server problem or the network connection timed out. Please wait a few minutes and try again.. I was not able to find a solution on Google so I started my own investigation.
I have been playing recently with the ETW (Event Tracing for Windows). One of my aims was to write a managed provider and try the ETW infrastructure in my application. Everything seemed to be well explained on the MSDN and not very hard to implement (especially in my simple case). Unfortunately not all things went smoothly and in this post I’m going to show you an issue I run into as well as some general path when diagnosing broken ETW providers.
Invalid session management is one of the common problems when using NHibernate and can lead to severe issues such as memory leaks or data inconsistency. In this post I am going to show you how to eliminate those pitfalls using the Visual Studio debugger. We will step through the process of opening and closing the session. We will also have a look at its properties in order to check if entities are correctly persisted. Let’s start then from breaking into the session open event.
To be able to debug the NHibernate source code the debugger must know how to find it. If you are using the 3.0.0 version of NHibernate you may use http://www.symbolsource.org configuring Visual Studio to use their symbol store. If your NHibernate version is different you need to either compile NHibernate on your own and reference the produced binaries in your application build process or make use of the sourcepack script. Here I will describe the second approach (especially because I’m the author of the sourcepack and I need to advertise it somehow ;)).
Have you ever wondered where Visual Studio 2008/2010 stores the source files that it downloads from the source server? By default they are put in your home directory under Local Settings\Applications Data\SourceServer. If you are using two different debuggers or you have more than one user using your machine you probably would like to change this location. Unfortunately there is no way to do that through the options dialog. You are left with two options described below:
- through registry – by changing a value of the SourceServerExtractToDirectory key in the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Debugger\ branch
- through options file – locate your Visual Studio settings file (its path should be displayed under Tools->Options->Import and Export Settings), then a tag: <PropertyValue name=”SourceServerExtractToDirectory”> and change it’s value to your desired cache directory
If you know any other way of changing this Visual Studio setting, please describe it in the comment.
I needed to test .NET com interoperability (as all debugging APIs are written in COM+) and so decided to implement my own simple COM+ component and then use it in my .NET application. I must warn you that I just started learning COM so if you are going to use this code you need to be careful :). Continue reading
I’m currently working on a simple debugger in VB.NET. I’m using mdbg assemblies to manage all the magic stuff happening between debugger and debuggee. I wrote following code in VB.NET just to handle process execution:
Public Class vdbg
Public Shared Sub Main(ByVal args() As String)
Dim debugger = New MDbgEngine()
debugger.Options.CreateProcessWithNewConsole = True
debugger.Options.StopOnModuleLoad = True
Dim process = debugger.CreateProcess(args(0), "", DebugModeFlag.Debug, Nothing)
and compiled it:
vbc /r:mdbgeng.dll /vbruntime- /debug+ /debug:full /t:exe vdbg.vb
As you can see this code is rather straightforward. New console window is opened for a “debuggee” and after debuggee finishes its execution both processes should finish. What happened was a big surprise to me. The new console window was opened and then both processes hanged. I wrote an equivalent in C# and it worked as expected. So the only thing that rested was to analyze the generated IL for both versions:
ildasm /item=vdbg::Main /out=vdbg.il vdbg.exe
I highlighted the controversial line of IL below:
.class public auto ansi vdbg
.method public static void Main(string args) cil managed
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 86 (0x56)
It appears that the VB compiler by default puts STAThreadAttribute above the Main method unless you don’t choose a different COM threading model. The C# compiler is not so eager in changing your code :). Be aware of that fact when writing multithreaded application. In my application adding the highlighted line resolved all problems:
Public Class vdbg
Public Shared Sub Main(ByVal args() As String)