I am working on adding a support for ASP.NET performance counters into Musketeer. Compared to other .NET performance counters they have quite surprising instance names. ASP.NET developers decided that their performance counter instances will be identified by names derived from the AppDomain names (more information can be found here). This is probably due to a fact that one process may host multiple ASP.NET applications, thus one counter instance per process won’t be enough. Consequently, in order to match collected metrics with process ids we need to know which AppDomain belongs to which process. How can we do that?
In the last post I presented you my first WinDbg extension with a !injectdll command. Theoretically everything was correct, but after some more testing I noticed that the command is not always working as expected. Andrey Bazhan was pretty quick in pointing this out and advised me to use a remote thread, which, as you will see, is a much better approach. But let’s first have a look at the problems in lld 1.0.
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) ntdll!LdrpDoDebuggerBreak+0x30: 00000000`778c7800 cc int 3
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:
<?xml version="1.0"?> <configuration> </configuration
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.