Reply
Bsod after debugging program?
Replies: 4   Views: 2197  Subscribers: 2

Posted by Justin · 13-05-2012 - 05:31

Something very frustrating and concerning has happened after attempting to debug a particular application of mine. Randomly I get the BSOD(blue screen of death) and it says: 'PROCESS_HAS_LOCKED_PAGES' and at the bottom 'dumping physical memory to disk'. At first thought I am dumb founded because I did not realize that an application alone could be capable of something like this. The worst thing is that I have yet to find an explanation and it happens randomly. My best guess was that it had to do with my background threads I had running and some how the thread caused some leak to happen in memory. I honestly have no clue what it is, but its a major concern regarding not only the application but my computer in general. I would like to know the potential cause to avoid a recurrence of this in the future. Any help would be appreciated.­

Posted by reece · 13-05-2012 - 06:06

Justin
At first thought I am dumb founded because I did not realize that an application alone could be capable of something like this.­
Programs are often the culprit of most BSOD's, that said an operating system is also comprised of programs (window manager, drivers etc), even the kernel is a program. The kernel usually delegates permission to access a region of memory and is the least likely culprit of a BSOD not that is impossible for it to happen. ­
Justin
Randomly I get the BSOD(blue screen of death) and it says: 'PROCESS_HAS_LOCKED_PAGES' and at the bottom 'dumping physical memory to disk'.­
The message within the BSOD stating that 'process has locked pages' would indicate to me at least that possibly some threads have locked memory blocks for the duration of its process while other processes are trying to access that memory block. I could be mistaken though. I believe locked blocks of memory by some of your processes are pending completion of another process, which is either depending on the value of that memory location or spawning more threads suffering the same fate. In the end you could have a large number of threads which have an interdependency on the result of the last and so if each thread is trying to access memory locked by another and is pending completion of the other to release access to it then nothing will move forward. If this is the case then the OS might realise this and decide to panic. I could be wrong of course. But this is what i suspect is the cause. I am really not that keyed up on how the kernel handles such events or further more the area of debugging complex multi threaded programs. However it could be a good start. If you have a decent debugger for C# though, i suggest monitoring the state of threads and seeing if they are in a state of pending access to locked memory. If the number of threads pending and hanging increasing until practically nearly all the threads are locked, you may need to rethink your strategy. I did find this interesting resource of memory locking, though it pertains to GNU C, most of the information is of a much lower level in nature and not exclusive to the language itself. ­Locked Memory­ which also has a link in the article pertaining to limits set on memory by the system for use in a process instance found ­here­

Posted by Justin · 13-05-2012 - 06:34

Edited by reece · 12-11-2012 - 05:17
Reece
Justin
At first thought I am dumb founded because I did not realize that an application alone could be capable of something like this.­
Programs are often the culprit of most BSOD's, that said an operating system is also comprised of programs (window manager, drivers etc), even the kernel is a program.­
Well firstly I didn't say 'program' I said application. And an application is software that a user runs manually and usually maintains an interface to interact with the user. A program is any executable file. Unless you claim my CompTIA A+ Cert Guide book to be incorrect not to mention the vast majority of the internet. But thanks for the information. ­
Reece
The message within the BSOD stating that 'process has locked pages' would indicate to me at least that possibly some threads have locked memory blocks for the duration of its process while other processes are trying to access that memory block. I could be mistaken though. I believe locked blocks of memory by some of your processes are pending completion of another process, which is either depending on the value of that memory location or spawning more threads suffering the same fate­
Ahh, that actually makes alot of sense and thank you for sharing. Because what I noticed is that it would only occur after multiple debugs of the same program. And the fact that a thread is locking a memory block would make sense since the issue seemed to be my way of killing the process. That is, I never actually killed the process until later on before I published the appliation I realized that I was calling the Application.Exit method but that isnt ending the program. Environment.Exit(0) was the solution I was looking for there. So that means that when you debug an application in visual studio, then close it with code but it doesnt actually end the process and then close it with the square stop button, it isn't freeing all the resources. I'm glad you have helped me put together this puzzle here, thanks alot reece.­

Posted by reece · 13-05-2012 - 07:25

Edited by reece · 12-11-2012 - 05:18
Justin
Well firstly I didn't say 'program' I said application. And an application is software that a user runs manually and usually maintains an interface to interact  with the user. A program is any executable file. Unless you claim my CompTIA A+ Cert Guide book to be incorrect not to mention the vast majority of the internet. But thanks for the information.­
I should of been more clear when i stated 'programs' in my original statements context, the point i was wanting to make is that software outside of the kernel domain are the most likely cause of most BSOD's not that it is exclusively the case though. This is because the kernel is just 1 program, usually fairly small and well written, vs an enormous amount of drivers, adapters, daemons and end user programs further compounded by numerous plugins that each program may have. Though the kernel can be affected and destabilised by kernel extensions if poorly written. There is very little real distinction between a program and an application. In actuality, Apple came out with the term Applications for its macintosh software back in the late 70-80's, Microsoft always used the term programs, as historically that is what they were always called. To this day apple still uses the term Applications for its desktop GUI programs, and utilities for its command line programs. In reality both are still programs. On windows Microsoft makes a similar distinction, with desktop GUI programs being called programs and command line programs being called utilities. In reality, be it graphical or not, command line driven or not it is still a program. Apple defined the term and still uses it to this day, Microsoft does not really use the term, or at least does not use it exclusively. If you open the start menu it still says 'programs', not applications. Though they do have in Windows Vista/7 the 'Applications' folder. This is nothing more than a partial transition to relabelling programs on windows to applications in the footsteps of Apple. Apple stores all its programs in the Applications folder and Microsoft seems to want to follow suit, keeping things tidier in the filesystem as Mac OS X does, they needed a name and choose Applications. In practical terms, an Application can be defined as software that 1) does provide a user interface and 2) is initiated by the end user, however it is still a program, even if a program is not an Application. ­
Justin
That is, I never actually killed the process until later on before I published the appliation I realized that I was calling the Application.Exit method but that isnt ending the program. Environment.Exit(0) was the solution I was looking for there. SO that means that when you debug an application in visual studio, then close it with code but it doesnt actually end the process and then close it with the square stop button, it isn't freeing all the resources. I'm glad you have helped me put together this puzzle here, thanks alot reece.­
It has been quite some time since i have dabbled in C# however i was under the impression when you hit the stop button (button being the rectangle icon for stop) in visual studio; it frees up all its resources. If thats not the case, how do you free them up?­

Posted by merryandy · 31-07-2013 - 10:36

Hi, I can be a bit later however i've just met the same issue debugging my program and found this answer which hasn't been mentioned in your discussion:

https://connect.microsoft.com/VisualStudio/feedback/details/691615

So my 5 kopeks is that if you deal with some BCL's Ping class, you don't have to worry because:
a) it's not your fault
b) it appears only if the interruption in debug mode occurs­