• The ever popular lists of CLR file versions that were useful for myself and others but became increasingly hard to maintain. Lists for 2.0 and 4.x.
• The old faithful "Nine tips for a healthy 'in production' ASP.NET application"
• The astonishingly well hit "Could NOT Load file or assembly - Part 1" which attracted about 10 times more hits than any other post over the years, probably because the blog title corresponds to an error message with innumerable possible causes [ and no, there never was a "Part 2" ].
• The rather off topic but hopefully interesting "Geomagnetic Storms–are they all bad?"
• My most obscure festive greeting ever represented in "A message to my readers" 
• The catchy titled "Random and unexpected EXCEPTION_FLT_DIVIDE_BY_ZERO and EXCEPTION_FLT_INVALID__OPERATION" which represents one of the gnarliest to debug class of issues
• The instructive "ASP.NET - how it uses Windows memory" which I was so pleased to 'rediscover' that I celebrated it as  "A long lost friend".
• Useful listicles like "An index to Maoni’s blog posts about the GC"
• Debugging and support 'war stories' like "You spent HOW much on our new server and the app slowed DOWN??!!"

Here 0x1234 would be the process ID of the process that we were attempting to dump. The Win32 error is 0x800700ea

The issue here was that one of my colleagues was having trouble generating a memory dump of a w3wp.exe hosting a particular web application. It kept failing with this error or some variant of it with just about any dump generating tool. Dumps of other web applications on the same machine were fine.

It turns out the root cause here was the full path of some temporary ASP.NET compiled module mapped into the process was too long and exceeded the system defined MAX_PATH.

The workaround is to configure ASP.NET to compile its temporary assemblies into some location with a shorter path by setting the tempDirectory attribute of the compilation element.

Thanks to Mourad and Joao for this one.

Doug

Anyway, turns out there is one – Ctrl+Alt+O

Of course, having figured that out, then I realised it also appears on the View menu (New Year’s Resolution – be more observant!) where it the shortcut is documented:

One small step for a developer….

Doug

If you are troubleshooting as a developer and you have the phone in front of you, connected to your PC, this is no problem. You can debug the app interactively from Visual Studio (and if you are debugging interactively you can even remotely capture a dump file and pull it back over the wire for later analysis at your leisure.

But what if you cannot get direct access to the phone all the time or debug interactively from Visual Studio?

Well, one option is to use the awesome utility Field Medic which you can install on the phone and use to collect diagnostic traces and information.

It has many uses but one thing it can do is capture crash dumps of crashing apps and also ETW traces originating from .NET/CLR telling you details of the crash.

Assuming you have a way to reproduce the app crashing on your phone, here is how to figure out why it is happening.

Launch Field Medic and select Advanced:

Tap on ‘Categories’ and deselect them all but select the ‘Performance_DotNetRT’ one:

This will capture Event Tracing for Windows (ETW) logs relevant to .NET/CLR.

Now if you also want to generate crash dumps for the issue (if you like delving into WinDBG) tap on ‘Choose your options’ under “Configure system log and crash dump options’:

Turn that on and select ‘Full’:

I won’t be going into the specifics of looking at the crash dumps in this blog post.

It is a good idea to minimise the number of apps running – just try to keep it to the app you are investigating. Traces are for the whole phone, not just your app.

Now back on the home page of Field Medic, tap on ‘Start Logging’ and you should see this after a moment or two:

Now reproduce the crash in your app, switch back to Field Medic (or re-launch it if it is no longer running) and select ‘Stop Logging’:

The ’Stop Logging’ phase may take a few extra seconds (sometimes quite a few!) if you have selected the Full Dump option.

You will be prompted to give your report a name and some contextual information:

Now connect your phone to your PC with and navigate to it in Windows Explorer:

If your phone was already connected to your PC, you may need to disconnect it and reconnect it before you see the new content on the phone file system. It seems to be a limitation of the USB based transport used to connect PC and phone that it does not auto-refresh. This was at least the case with Windows Phone 8.1 though it seems to be fixed in latest Windows 10 Mobile builds from what I can tell.

Navigate into the “This PC\Windows Phone\Phone\Documents\FieldMedic\reports” folder and copy the entire report folder off the phone. The report folders have names like this:

WPB_000_20160420_120713

Field Medic traces, among other things, captures Event Trace Log (ETL) files. There are various ways to read these specially formatted files but one of the most fast and convenient I find is the multi-talented PerfView.

Navigate into the report folder to locate the single ETL we collected:

and open it with PerfView.

Once in there, in the PerfView UI navigate to the ‘Events’ node under the node for the ETL:

This will open a new window for exploring the ETL contents

Now type ‘exception’ into the event types filter box and click update:

Hopefully you will now see a filtered list of events on the right. Note there may be some innocuous exception events going on from other apps that are not relevant.

In this example however we can see an entry from my app, which is called App2 (ok, so perhaps I am not cut out for marketing!)

If I click on that event and Ctrl+C here is what I get:

“HasStack="True" ThreadID="704" ExceptionType="System.NullReferenceException" ExceptionMessage="Object reference not set to an instance of an object." ExceptionEIP="0x35f1d36" ExceptionHRESULT="-2,147,467,261" ExceptionFlags="CLSCompliant" ClrInstanceID="10" ”

If it is a complex app with other non-crashing exceptions going on you might need to look at whether that was the last event logged by that instance of App2 to know whether it was the exception that brought the process down or not.

In this case, we now know that at System.NullReferenceException killed the process at instruction pointer address 0x35f1d36. Hmm, interesting but maybe not useful, yet.

Note, however, the HasStack=”True” in the above. Sounds useful, right?

Close that PerfView window you’ve been working in and go back to the primary window. Navigate into the “Advanced Group” and double-click on ‘Exception Stacks’:

You’ll get a process selection window open – now double click on the entry for your app:

A new window will appear showing stacks for exceptions that happened within the App2 process during the trace. In this case there is only one and it is the exception we are interested in:

Thankfully, this time, it tells me the function in my app where the exception was thrown. That is enough of a clue to get me on the right track and figure out what went wrong.

If you need to go deeper and you selected the Full Dump option earlier, you will find the full memory dump in the Documents\Debug folder (on Windows Phone 8.1):

If you are looking for the dump file on Windows 10 Mobile, it seems things have changed slightly and Field Medic pulls the dump file out of the Documents\Debug folder and CABs it up with Watson telemetry data within the Field Medic report:

Of course, I could have instrumented my app with HockeyApp and got crash reports that way .

Here are some additional references:

Use Field Medic to generate a report

Windows/Phone 8.1 Debugging: Getting a Crash Dump File From a Device

HTH

/D

Version number indicated refers to CLR.DLL. If there are patches of significant interest relating to other files I’ll note that in the ‘File’ column.

Additional useful references

Introducing the .NET Framework Monthly Rollup

.NET Framework Monthly Rollups Explained

.NET Framework Monthly Rollup: October 2016

.NET Framework December Monthly Rollup is Now Available

Targeting Packs

Application Compatibility in the .NET Framework

.NET Framework downloads

How to: Determine Which .NET Framework Versions Are Installed

What's new in .NET 4.6.2

What's new in .NET 2015 (.NET 4.6 and .NET Core)

What’s new in the .NET Framework 4.5.2

What’s new in the .NET Framework 4.5.1

Clarification on the support life cycle for the .NET Framework 3.5, the .NET Framework 3.0, and the .NET Framework 2.0

HTH

Doug

Find out more about Red Hat solutions on Azure here.

/D

In this case, the customer was using the Apache Cordova tooling for Visual Studio. We’d confirmed they were using the latest version of this, which at the time was Update 6.

Even a simple app created from the provided template would not build.

The build log was showing this:

1>         npm ERR! code EJSONPARSE
1>         npm ERR! Failed to parse json
1>         npm ERR! Unexpected token '\u0000' at 1:1
1>         npm ERR!          npm ERR! ^

With quick input from the our team in Redmond that work on this it was clear the customer’s NPM cache had somehow got corrupted.

Suggestion was to clear the cache, by shutting down Visual Studio and deleting the contents of “C:\Users\[USERNAME]\AppData\Roaming\npm-cache”.

Happily, this fixed it.

HTH

Doug

Following on from my “Version history of the CLR 2.0” post I’ve decided to start one for 4.0.

The below generally only refer to patches affecting core CLR files clr.dll, not the rest of the framework, although I meant mention one or two other fixes with affected DLLs noted.

The following version numbers refer to the final revision number part of the full file version number, in other words the xxxx bit of 4.0.30319.xxxx

I am slightly embarrassed by the length of time since my last blog post. But never mind, here I am again!

I’ve been working on a customer issue lately where an existing Windows Store app was failing on Windows 10. Initially the app, which ran fine on Windows 8.1 was crashing when installed and run, unaltered, on Windows 10.  The code involved looked something like this:

           var vault = new PasswordVault();
         
           // Add the new credential
           var passwordCredential = new PasswordCredential("test", "user", "password");

           try
           {

               // *** This should not give an error ***
               vault.Add(passwordCredential);
               return "Successfully added credential!";

           }
           catch (Exception excp)
           {
               return "Failed!" + excp.ToString();
           }

PasswordVault is a handy class that allows you to securely store credentials used by your Windows Store or Windows Phone 8.1 app.

The .NET exception thrown was System.ArgumentException with the text “The parameter is incorrect. Cannot add credential to Vault”.  Of course, without the exception handler the app was crashing. With the exception handler it was not crashing but the credentials were not stored either. Not very useful.

As is often the way when debugging, I started by getting the customer’s solution into a state where I could compile and debug it locally, eliminating dependencies I did not have or need.  At that point I could reproduce the issue.  Next step was to start from a blank solution and build it up, adding similar code to that used in the customer’s solution. Interestingly that did not fail! So there had to be some other factor.

Anyway, to cut a long story short, it turned out this is a corner case that depends on the full app names length.  As a result, this only affects a very small number of apps.  The good news is that we got a bug filed and a fix through the system which has now been released, as of yesterday’s cumulative update:

Cumulative Update for Windows 10: August 27, 2015 (KB3081448)

Hope that helps

Doug