Getting a blue screen of death when stopping debugging in Visual Studio (Ping, PROCESS_HAS_LOCKED_PAGES)
As you know from the previous post, I am working on a network monitor application that displays information about the devices in my local network. For that I need to ping them to see if they are available. The simplest solution is to use the out-of-the-box solution of System.Net.NetworkInformation.Ping. It was no little shock to stop debugging my application and find myself facing a Blue Screen of Death, you know, the blue thing with white text that means everything is fucked, with the error message PROCESS_HAS_LOCKED_PAGES.
Googling around I found that the problem is, indeed, coming from the Ping class. Since the application is full with BackgroundWorkers and threads and stuff like that, Ping was actually the furthest from my mind. I even suspected that my laptop is dying. Microsoft, blessed be their hearts, not only did they ignore the bug, which is logged on their Connect site, but they eventually closed it with no resolution. Therefore I resolved to find a solution by myself.
I tried to see if there are any alternatives to the Ping class. I downloaded two implementations: PingWin and Pinger, both seemingly functional. PingWin, was using the Windows IcmpSendEcho function, via Pinvoking icmp.dll. Pinger was using raw sockets. After replacing the Ping class with a class with the same members and properties I was using, but wrapping PingWin, I checked to see if the application was behaving as expected, then stopped debugging. Again I got the BSOD, suggesting what I had read from other people with the same problem, that it is not a .NET managed code issue, but instead it is a problem stemming from the lower level code in the Windows operating system.
As noted in the IcmpSendEcho documentation, there are two implementations, one included in Icmp.dll, which comes from Windows 2000, and one included in Iphlpapi.dll, which comes included in Windows XP and later. Replacing the target of the DllImport attribute to Iphlpapi.dll resulted in an application that works exactly the same, crashing just the same. Looking at the source code of the Ping class, I see that it is using the same mechanism, calling the functions exported by Iphlpapi.dll.
Using the raw socket implementation did not cause a crash, though, so I can recommend you use it, if you can, since everything using Iphlpapi.dll or Icmp.dll seems to be affected by this. There are some limitations to using raw sockets in Windows, but I think ICMP may be exempt. You should research some more if you want to use it in an application that must work in all kind of security environments.
Googling around I found that the problem is, indeed, coming from the Ping class. Since the application is full with BackgroundWorkers and threads and stuff like that, Ping was actually the furthest from my mind. I even suspected that my laptop is dying. Microsoft, blessed be their hearts, not only did they ignore the bug, which is logged on their Connect site, but they eventually closed it with no resolution. Therefore I resolved to find a solution by myself.
I tried to see if there are any alternatives to the Ping class. I downloaded two implementations: PingWin and Pinger, both seemingly functional. PingWin, was using the Windows IcmpSendEcho function, via Pinvoking icmp.dll. Pinger was using raw sockets. After replacing the Ping class with a class with the same members and properties I was using, but wrapping PingWin, I checked to see if the application was behaving as expected, then stopped debugging. Again I got the BSOD, suggesting what I had read from other people with the same problem, that it is not a .NET managed code issue, but instead it is a problem stemming from the lower level code in the Windows operating system.
As noted in the IcmpSendEcho documentation, there are two implementations, one included in Icmp.dll, which comes from Windows 2000, and one included in Iphlpapi.dll, which comes included in Windows XP and later. Replacing the target of the DllImport attribute to Iphlpapi.dll resulted in an application that works exactly the same, crashing just the same. Looking at the source code of the Ping class, I see that it is using the same mechanism, calling the functions exported by Iphlpapi.dll.
Using the raw socket implementation did not cause a crash, though, so I can recommend you use it, if you can, since everything using Iphlpapi.dll or Icmp.dll seems to be affected by this. There are some limitations to using raw sockets in Windows, but I think ICMP may be exempt. You should research some more if you want to use it in an application that must work in all kind of security environments.
Comments
Be the first to post a comment