I'm confused, the docs for the IOCTL don't say anything.
The docs for fsutil say:
- 0x01: Enables general repair.
- 0x09: Warns about potential data loss without repair.
- 0x00: Disables NTFS self-healing repair operations.
The fsutil program itself says:
Values: 0x1 - Enable general repair.
0x9 - Enable repair and warn about potential data loss.
0x10 - Disable repair and bugcheck once on first corruption.
So which one is correct? Does 9 do repair and issue message or does it not do a repair an only issue a message?
TIA!!
Take a look at the following MSDN page.
It is apparent that being warned of errors requires that self-healing be turned on to begin with. Keep in mind that 9 is 8|1.
Related
I have a client who received an error message when their Foxpro application initiated, Foxpro v9.0 error msg: "Unrecognized Database Format".
My client reported that he had a power failure and the problem appeared after he rebooted the PC.
It appears that the foxpro database corruption was caused by the power failure.
Any suggestions, friends...
Here is a link for VFP code to repair corrupt table headers in VFP. Provided you have VFP, it basically does a low-level file open, checks entire file size, detects record size and resets the record count. I have a client who still has VFP apps going, and once in a great while, they too have whatever power outage / surges / network connectivity issues and corrupts the header. They run this routine and back in business...
In addition to fixing the data or restoring a back-up, you should make sure there's an Uninterruptible Power Supply for every computer on which your application runs. Then, in the event of a power outage, your customers can shut down gracefully and avoid this kind of problem.
I have been struggling to detect a memory corruption error in our product. The memory detection tools like valgrind only tell the problem at the time of the crash, not when the corruption actually occurs. I have seen while using debug builds that it will check the memory area before and after the block being freed, and show a debug assertion failure saying a heap corruption has occured. So can I rebuild my product in debug mode to capture the error right when it occurs? Will it also catch buffer overruns etc? I could not find any information on the internet about debug builds being targetted towards memory error detection.
You can use as well the 'Page Heap' available on every version of Windows.
You can use gflags that comes along to Debugging Tools for Windows to configure Full Page Heap for your application.
You can then run your application, even in retail mode, under the debugger. The debugger will stop once you encounter a buffer overrun or access to freed memory.
I like very much this tool, because it is built in the OS, an can even be activated on a customer site (gflags only sets registry keys and you can simply send these keys to your customer).
Some people are afraid when we mention (Debugging Tools for Windows). You can use Visual Studio to diagnose the problem. The only thing you need are the PDBs corresponding to your binaries (you can generate them even for release builds).
I am not sure about the debug builds, but for a nice overview of memory corruption tools you might look at http://code.google.com/p/address-sanitizer/wiki/ComparisonOfMemoryTools. It list Valgrind and what it should be able to check for you.
"C++" is not a compiler; vendors make their own according (more or less) to the standard specs.
I only have experience with Microsoft's, and I can tell you that it checks heap corruption by allocating "sentries" around each new or malloc block (in debug mode only, of course) and filling them with a special pattern (was 0xCD when I last used it), and then it checks the guards for every write around that location. If they changed, you'll get a run-time error saying the heap got corrupted.
By the way, buffer overflows are heap corruption.
Edit to add a reference: http://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx
I am working on a Windows Embedded Standard 2009 project deploying on an Atom powered tablet. We have some known Windows bug check crashes (BSOD) that I am working through. We also have a bug where the tablet becomes unresponsive with the screen off; requireing a hard power cycle to recover. I am pursuing a theory that the unresponsive tablet is a BSOD crash that happened with the screen off. We have EWF turned on which prevents a memory dump from writing to know if a BSOD occurred. We turn the monitor off after user inactivity using user32.dll SendMessage(Handle, WM_SYSCOMMAND, SC_MONITORPOWER, MONITOR_OFF).
Will a Windows bug check (BSOD) turn on the monitor if it was turned off previously programmatically?
Thanks!
Can't speak for tablets, but the bug check isn't going to jump into a long series of power maangement routines, just to output the fact that it's exploded. The bug check does as little as is physically possible, since once you're in BSOD mode, the system is by definition already crashed and not stable and in a highly unknown state. Starting to call other complicated subsytems is not going to happen, as the BSOD may very well have happened in the very routine(s) it's trying to call.
No, bug checks do not turn on the monitor (doesn't matter if it went to sleep due to inactivity or your message).
Your best bet is to leave a kernel debugger attached.
While bugcheck does not go through any power management code, it does make operations that would usually wake a monitor up. Bug-check changes screen resolution and switches to text-mode. If you have a kernel-debugger attached (or just configured), the system waits for the kernel debugger response and will not display the blue-screen text until you hit "g".
In the default configuration it will also attempt to create a crash-dump and reboot. If you suspect a bugcheck look for memroy.dmp in the windows directory or connect a kernel debugger.
Is there any way to detect if a BSOD has just occurred(before the OS shutdowns)?
Thanks,
The kernel provides limited functionality for drivers to be informed of a bugcheck (i.e., BSOD) via KeRegisterBugCheckCallback. In the callback routine, you can attempt a graceful shutdown of your applications, etc. However, given that the system is bugchecking, most functionality will not be available.
Not to my knowledge. A BSOD usually means a hardware malfunction which results in the computer not being able to work/run.
If you have experienced one BSOD it would be wise to investigate the report document as the BSOD is most likely to return.
Most frequent causes are drivers not being up to date or memory malfunction. I have also seen hard drives cause BSODs.
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.