This post is the second and final one dedicated to debugging .NET Windows services (you may read the first one here). The inwrap tool (presented in the first part) is not very friendly to use and I myself haven’t used it since then :) It’s not the best advertisement of someone’s own work, but it did motivate me to write another tool which maybe will gain your interest. The winsvcdiag is a simple application that allows you to debug a start of a Windows service from Visual Studio (or any other debugger – even the remote one).
I recently had an interesting issue in one of our applications. The SMS router, responsible for sending and receiving SMSes, hanged – there was no CPU usage and we haven’t observed any activity in the application logs. I collected a full memory dump and restarted the service, which seemed to come back to its normal state. Curious what happened I opened the dump in WinDbg, loaded PDE and SOS and started an investigation
In one of our applications I recently observed timeouts in code performing HTTP requests to the REST service. While investigating this issue I discovered few interesting facts about System.Net namespace and would like to share them with you. We were using objects of type System.Net.HttpWebRequest in our code, but some of the information presented in this post will also apply to the newer System.Net.HttpClient implementation.
This one would be short :) While learning new things I write notes, collect help files and sample code. I use my Google Drive to store them. I have decided recently that some of the folders may be worth publishing and this is how Debug Recipes repository was born. I have a plan to store in it:
- instructions how to resolve various problems in applications
- instructions how to use debugging/profiling tools and features available in them (example for Visual Studio)
- scripts that may help you in debugging (example for collecting .NET exceptions in production)
I’m still working on a better navigation (each section will have a README.md file), but for now the Github search and folder navigation are the only options. As you can imagine it will always be a work in progress, but I hope that some recipes will prove useful to you. As always comments and suggestions are welcome.
Diagnosing Windows Services might sometimes be cumbersome – especially when errors occur during the service start. In this two-parts series I am going to show you different ways how to handle such problems in production. In the first part we will focus on “exceptions discovery” techniques which very often are enough to figure out why our service is not working. In the second part we will setup a debugging environment and attach a debugger to our service. Let’s start then.
I decided recently I need to learn Python. It’s a great scripting language, often used in forensics, diagnostics and debugging tools. There is even a plugin for windbg that allows you to script this debugger in Python language, but it’s a subject for another post. Moving back to learning Python – as an exercise I wrote a simple tool to decrypt ASP.NET Identity cookies and ASP.NET Anti-Forgery tokens. You may find it useful in situations when you need to diagnose why one of your users can’t sign in into your applications or is not authorize to access one of its parts. It does not perform validation but only decrypts the content using 256-bit AES (let me know in comments if you need some other decryption algorithm to be implemented). Adding validation logic shouldn’t be a big deal and the nist library (which I used for cryptographic operations) provides all the necessary functions.
ASP.NET Identity is a big step forward and we should profit from its features, such as: two-step authentication, support for OpenId providers, stronger password hashing and claims usage. One of its requirements is .NET4.5 which might be a blocker if you have in your farm legacy Windows 2003 R2 servers still hosting some of your MVC4 (.NET4.0) applications. In this post I would like to show you how you may implement common authentication and authorization mechanisms between them and your new ASP.NET MVC5 (and .NET4.5) applications deployed on newer servers. I assume that your apps have a common domain and thus are able to share cookies.