I'm getting a lovely BSOD on bootup (STOP: 0x0000007E) from a driver I'm writing, and would like to load up the memory dump for analysis. However, it's not getting dumped anywhere. Everything is setup correctly in the Startup and Recovery settings, but I get no dump file, and nothing in the event log stating a dump has taken place. It looks like a dump is not even occurring...
I know the exact line of code causing it (a call to IoAttachDevice()), but am not sure why, and would like to view the DbgPrint output to see where exactly it's failing. Could Windows possibly be crashing before the dumping functionality is set up? If so, how do I get access to the state of the machine when the failure occurs?
UPDATE: Other possibly useful information: I'm running Windows XP through VirtualBox on a Linux host.
I don't know why you're not getting a dump file, but if you have ready access to the machine, attach a kernel debugger to it an repro the error - you'll be left with the machine sitting in the debugger, ready to go (you can have the debugger produce the dumpfile for you if you want to debug offline as well).
Right-click on "my computer" select "Advanced", under "startup and recovery" click "settings". select "kernel memory dump" or "complete memory dump".
What's the start setting of your driver? If it starts too early in the boot order, the filesystem might not be remounted read-write yet, and therefore there's no place for a dump to go.
Drivers under development shouldn't generally be set to auto-start until you've gotten the driver stable when loaded later. Of course you eventually need to set it to auto-start so you can verify it works correctly, but that comes later.
Related
Occasionally when I restart Win10 x64 I get an application error from my system tray utility in the from of:
AppName in Title bar
The instruction at 0xXXXXXXXXXXXXXX referenced memory at 0xXXXXXXXXXX.
The memory could not be read.
over the top of the This app is preventing you from restarting.
But there are no .dmp files created. I have Windows set to create the dump files and in the normal course of things it does, just not this particular one on a restart/shutdown.
I also can't find anything in the Event Viewer to at least get the base address so I can do some basic math to find the offset to the instruction.
Any tips on how I can get a .dmp created for when this happens or some type of information to help diagnose the issue on reboots?
There are occasions other apps (not mine) do the same thing on a restart so not sure if this is normal? Doesn't see like it should be.
I have a program that has been built in "release with debug info" mode. Sometimes it crashes on the user side, but when I try to recreate it on my computer -- everything is fine. I'm looking for debug tool or something that would allow the user to snatch a crash dump and send it to me so I could at least see the call stack. What would be a suitable tool to do that? What can I navigate such dump with? After a brief searching I didn't find anything suitable, so I hope for your help. Thank you very much in advance!
Window Error Reporting (WER) is the Microsoft mechanism to capture crash dumps in OS code and Application code. If you use the default settings, the crash dump is sent to Microsoft servers and eventually deleted if you do not have a WER account. However, there is a way to trap the dump locally on a user's machine. In order to collect user mode dumps, you need to set some registry keys. I've done this with my customers by creating a small program that sets the necessary keys so that I can trap the dump. I send them the program and instruct them to email the dump file to me.
Note: You'll also need to make sure that you have available the matching debug symbol files (.pdb) when debugging the crash. Otherwise, the collected dump file is somewhat useless.
I am using foxpro apps under Windows 7. During the compilation one of my program it suddenly became freezing until I move the mouse or press any key. And this happens all the time while I am working with prog.
This happens when I move only the data to a mapped directory on the host. If my application, foxpro and the data are in the same directory on the virtual machine there are no problem with it.
This happens when my data is not on the virtual machine.
Can it be a caching issue?
Change the registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW]
Save export as backup. Then change value "DefaultSeparateVDM" to "yes"
If you have 64bit then you need to create a file for 16bit applications that use the internal start command in separate memory space as follows:
Start /separate command
Also have a look at this article. http://www.reddit.com/r/Database/comments/2kz0x5/dbf_file_getting_corrupt/
There kind of similar problem, who knows, maybe it would be helpful for you
I have run into similar in the past, and it doesn't have to do with VFP application and data residing in the same folder. What has happened to me is the debugger. You mention "...while I am working with the prog." tells me you are in the VFP development mode, and not run-time from the app itself. If you have issues where your debugger has breakpoints, or other flags that have become corrupted somehow, I have done
CLEAR DEBUGGER
But that is something going back several years and MIGHT be what you are encountering.
I have a machine that periodically BSOD's. I have full memory dumps configured. Sometimes, when rebooting AFTER the BSOD, the machine sits on a black screen for several minutes, then finally comes up to windows. My colleague just recently found out that during this time, the machine was writing the full memory dump to disk.
He identified this by shutting the machine down on the BSOD, plugging the drive in as a slave, seeing that no dump file was present, plugging it back into a machine, seeing the black screen for several minutes, and then finding the memory dump on disk.
So my question is, how does this work, internally? I swear I've seen the BSOD itself telling me that it is currently writing the dump file to disk, with a counter.
What's happening is that the BSOD overwrites the pagefile with the full contents of memory in order to avoid doing any complicated processing after a critical system error (bear in mind that the cause of the BSOD could have damaged any heaps, code, unloaded drivers etc, so the BSOD basically can't rely on anything). When the system reboots it discovers that the pagefile's been marked as a BSOD, and then sets about converting the RAW dump to a minidump file that can be analysed either by Microsoft's crash-reporting server or by a driver developer analysing the crash dump in WinDbg or Visual Studio.
While I don't know for sure, its possible that it has to write RAM to disk while displaying the screen, but when it reboots, it pulls the rest of the process memory space out of the swap file to create the full core dump.
This is the first time I hear something like that. I though the dump was always writting while the BSOD is shown. You can try to connect the kernel debugger in verbose mode and figure out what's happening.
I've recently started seeing this line in my Visual Studio 2005 output window when launching my application:
FTH: (7156): *** Fault tolerant heap shim applied to current process. This is usually due to previous crashes. ***
I've tried turning off the fault tolerant heap using the instructions here:
http://msdn.microsoft.com/en-us/library/dd744764(VS.85).aspx
I'm running Windows 7 64-bit edition, so I have made the changes to both the 32-bit and 64-bit registries, and run the "Rundll32.exe fthsvc.dll,FthSysprepSpecialize" command using both the 32-bit and 64-bit versions of Rundll32.exe.
However, after rebooting I am still getting the fault tolerant heap when trying to debug my application!
This is a real problem since it masks the bug I am trying to reproduce, and it also kills performance.
Does anyone have any other suggestions how to disable the fault tolerant heap?
To disable it for a single application
Go to the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER versions of
Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers\your_application.exe and
delete the FaultTolerantHeap entry.
From here (actually here)
Set this registry value to 0:
HKEY_LOCAL_MACHINE\Software\Microsoft\FTH\Enabled
You can add the name of your executable to the ExclusionList.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH\ExclusionList
Works for me.
You can edit the application manifest to excluding your program from PCA
see also:How to reset Program Compatibility Assistant for testing
you can clear the list of applications tracked by FTH without stopping this service by following these steps:
Click the Start menu.
Right-click Computer and click Manage.
Click Event Viewer -> Applications and Services Logs -> Microsoft ->
Windows -> Fault-Tolerant-Heap.
View FTH Events.
you will find file named operational by right click and choose clear log,
then you can run you program again and warning message will disappear,
it worked with me without restarting operating system.
On Windows 10 the registry location is:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH
You can remove you executable from the list in:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH\State
or you can run this command from an elevated command prompt
Rundll32.exe fthsvc.dll,FthSysprepSpecialize
You may need to reboot your machine
"Rundll32.exe fthsvc.dll,FthSysprepSpecialize" looks to only clear the list of currently flagged applications. if your application still causes oddities, the FTH should still step in and take over.
as already mentioned:
Set this registry value to 0: HKEY_LOCAL_MACHINE\Software\Microsoft\FTH\Enabled
this should disable FTH for the whole system.
I had to rename the file as well because the registry entries associated with this key were empty of applicable data. I expect that they populate if you have a misbehaving application. But in my case I was debugging my own application within Visual Studio. So in that case, it was my process that was somehow loading the FTH whether the FTH Service was running or not. And in fact I had no applications listed that were previously tagged as misbehaving.
But I had to follow these instructions:
http://billroper.livejournal.com/960825.html
because it wouldn't let me rename the file until I took ownership and made sure I had full control.
I had similar issue when running a Unit test using (Microsoft::VisualStudio::CppUnitTestFramework).
Somehow I had violated some heap allocation, and next time I tried to debug I received the message : "Fault tolerant heap shim applied to current process. This is usually due to previous crashes. " and the debug environment froze.
To get it to work again, I had to remove test case, recompile and add it again and recompile, then I could set breakpoint and step into the test.
Also ran into this. Renaming/deleting AcXtrnal.dll inside Windows\AppPatch seems to work for me. I like how this Microsoft recommended action (which I did first) does nothing.