Hidden catch when using linked CancellationTokenSource


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:

Continue reading

The truth about app_offline.htm


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

and app_offline.htm:

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?

Continue reading

Diagnosing a Windows Store connection problem


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.

Continue reading

A managed ETW provider and the 15002 error


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.

Continue reading

Debugging NHibernate: session management


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.

Continue reading

Debugging NHibernate: prepare symbol files


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 ;)).
Continue reading

Visual Studio source server cache


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.

VB.NET compiler and STAThread attribute


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:

Imports System
Imports System.Reflection
Imports Microsoft.Samples.Debugging.MdbgEngine

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)
    While process.IsAlive
      process.Go().WaitOne()
    End While
  End Sub
End Class

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
       extends [mscorlib]System.Object
{
  .method public static void  Main(string[] args) cil managed
  {
    .entrypoint
    .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) 
    // Code size       86 (0x56)
    .maxstack  5

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
  <MTAThread()> _
  Public Shared Sub Main(ByVal args() As String) 
     ...