Click here to Skip to main content
15,355,133 members
Technical Blog
Posted 6 Nov 2015

Tagged as



1 bookmarked

My first exception caused solely by .Net Native

Rate me:
Please Sign up or sign in to vote.
4.67/5 (2 votes)
6 Nov 2015CPOL2 min read
In a current project we’re developing a UWP application which, as you may or may not know, *requires* you to compile to .Net Native in order to submit to the store. No biggie, that hasn’t been a problem. Until now.

In a current project we’re developing a UWP application which, as you may or may not know, *requires* you to compile to .Net Native in order to submit to the store. No biggie, that hasn’t been a problem.

Until now.


We had a tester come to us with the app installed from the store yesterday reporting the app seized up and crashed upon their first click/tap within the app.


No matter how hard we tried, Debug mode, Release mode, x86, x64, mobile, tablet, we couldn’t reproduce.

Until we turned on .Net Native tool chain in the project compilation options:


The second we did this, boom.

It left us scratching our heads but there was one thing we *had* added to the app recently that seemed like it could be the culprit:


We had a backend service which used SignalR to stream data to our app. The SignalR libs we were using are the ones from Microsoft: AspNet.SignalR (available on NuGet).

When we dug in to where and why the crash was happening, it was in this code:

if (_connection != null)

    _connection = null;

turns out – only when in .Net Native – the call to .Stop() caused a NullReferenceException to be thrown from the bowels of the SignalR libs and, since the Stop() call is synchronous, it seized the app while the exception bubbled and percolated through before finally crashing the process.

How did we fix it?

Turns out it’s somewhat of a hack but hey, it works – at least until the SignalR folks on the AspNet team figure out how to play nice with .Net Native:

//Found that when compiled .NET Native that tearing down the connection can take 30 seconds and
//result in huge exceptions and failures.
//We are going to task this out.
Task.Run(() =>
    if (_connection != null)
            //Give the connection 3 seconds to stop. If it doesn't, then just eat all exceptions and move on with life.
            //_connection.Dispose(); -- Sounds like Dispose is the same as _connection.Stop, no need to double up on the calls.
            //^ Left this here as a tombstone for future people. If there are bugs, feel free to use Dispose, but then you don't get the
            //nice timeout parameter that Stop provides.
            //When we compile release / .NET native the connection object behaves erraticly and can throw exceptions.
        _connection = null;
    _hubProxy = null;


The comments basically explain the approach, but to spell it out:

  1. Stop your connection on a background thread/task so the UI isn’t locked while Stop() executes (remember it’s synchronous).
  2. Eat any exceptions that might occur during stop; we at least were going to be throwing the connection away anyway.
  3. Provide a timeout for the Stop() call so it doesn’t try and seize your UI while it’s executing.

After doing this, our app behaved exactly as it needed to with respect to our usage of our SignalR backend and its connection creation & disposal points.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Software Developer (Senior)
United States United States
I'm a Sr. Software Engineer in the Seattle area primarily focused on serverless technologies in the cloud. In my free time I enjoy hiking & other adventures with my family around the Puget Sound and the country! You can find out more about me at my homepage:

Comments and Discussions

Suggestionvery broad trap Pin
Israel Alonso9-Nov-15 6:53
MemberIsrael Alonso9-Nov-15 6:53 
I'm glad the solution works. From time to time I am called to troubleshoot code that looks like this, with no idea why the behavior is different than expected. By swallowing whatever happened, you have now forever lost valuable information as to what really happened behind the scenes, that may have you chasing your tail for a LONG time.

At any one time a large number of exceptions could be raised. I would suggest considering at least recording and allowing retrieval of this exception information by the user, such that if something other than you expected exception occurs in the future, you can see the difference between the "normal" error you meant to trap, and whatever else got really thrown.

Good Luck,
Israel Alonso

GeneralRe: very broad trap Pin
BC3Tech9-Nov-15 7:54
MemberBC3Tech9-Nov-15 7:54 
QuestionSignalR Hub Pin
tommasuth9-Nov-15 5:00
professionaltommasuth9-Nov-15 5:00 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.