my .net program is causing a BSOD

Question

I am getting a blue screen when my windows winform application is run. It seems that only one user is getting this. I am not sure where at this time to look for the problem. I am however using some code that I found on CodeProject to trap mouse events and keyboard events http://www.codeproject.com/KB/cs/globalhook.aspx could this possibly be it?

I am looking for suggestions on how I might trap this error. It's only happening on one users computer out of 40, so I am a little perplexed - especially since this user is the primary stakeholder.

Update: We have one more incident - the common denominator is the docking port. The user was using the same docking port.

Answer 1

It is impossible for your code to be causing a BSOD. If you're not running in kernel mode, then a BSOD isn't your fault (if you'll excuse the pun).

OTOH, I have seen managed code trigger a bug in a piece of kernel-mode code. This bug then caused a BSOD. In my case, the kernel-mode code was part of a piece of VPN software that wanted to understand what code you were running so it could decide whether or not to allow you access to the VPN. The code was using kernel-mode hooks to do this, and they had a bug that was triggered by the loading of large numbers of assemblies.

Apparently, they had never tested their code while Visual Studio was running. It loads add-ins and such at runtime, which triggered their bug. A piece of C# code that simply loaded large numbers of assemblies into an AppDomain (then unloaded the AppDomain and started over) also triggered their bug, so it wasn't a Visual Studio problem.

The moral of the story is that someone needs to look at the crash dump and figure out which piece of kernel-mode software caused the crash, then maybe you can figure out what was going on in the system to trigger the kernel-mode software to crash.

Answer 2

The problem isn't going to be your app directly, but some issue with his system, so as roufamatic says check is event logs. However there are two common 'hardware' errors that tend to cause this sort of issue and you could profitably check these to see if they[ll give you a lead.

1. Bad memory. If a memory error has developed it's not unusual to see a particular program that can 'cause' the bad memory to be accessed and so lead to a BSOD. If for example he's generally running fairly lightweight applications then it's possible for the memory error to be in a location that is not normally used. When you load up your app - particularly if it's got a large memory footprint and calling in lots of dependencies, you may well trigger the crash indirectly. So run a full check on the machine RAM.

2. Printer drivers. This used to be more of a problem than it is now, but if you're running on XP then it still does pop up occasionally. Printer drivers are notoriously badly written and quite often buggy. It's not unheard of for an app to call a printer driver which in turns crashes the system. To check this just remove the printer drivers then reload them again afterwards.

EDIT: As pointed out in comments, any bad hardware or bad drivers can cause this sort of behaviour. I simply highlight memory and printer drivers because experience shows that these two are by far and away the most common causes so worth considering first.

Answer 3

I've had to solve this problem before. I was writing user-mode C# code to talk to a HID device on the USB bus. This problem occurred on my laptop but on nobody else's machine. It turned out that it was causing problems because I was running a 64-bit OS and hence had 64-bit drivers. All other users had 32-bit drivers, which didn't have the problem. This was a mildly controlled set of users. I knew each user and they were competent users who could give me information about their hardware, OS and drivers. We were also all using the same device.

I don't remember how I DETERMINED the problem. But I solved it quite simply by setting the application project to only target 32-bit Windows. Without a 64-bit app, the faulty driver is never used.

Have the users update their drivers, their hardware, or change the code to avoid using the driver altogether.