Why is my DLL using Fault Tolerant Heap?

Question

I am getting a crash when a DLL written in C++ unloads. It looks like this has something to do with heap corruption. Based on the following partial stack trace, I think my application is trying to use Fault Tolerant Heap. I have tried to turn this off to reveal the original source of heap corruption, but I don't think this is working.

ntdll.dll!RtlReportCriticalFailure()  + 0x56 bytes	
ntdll.dll!RtlpHeapHandleError()  + 0x12 bytes	
ntdll.dll!RtlpHpHeapHandleError()  + 0x7a bytes	
ntdll.dll!RtlpLogHeapFailure()  + 0x45 bytes	
ntdll.dll!RtlpFreeHeapInternal()  + 0x4e0 bytes	
ntdll.dll!RtlFreeHeap()  + 0x51 bytes	
AcLayers.dll!NS_FaultTolerantHeap::
	APIHook_RtlFreeHeap()  + 0x431 bytes	
ucrtbase.dll!_free_base()  + 0x1b bytes	
Physics_Output_Suite_DLL.dll!std::_Deallocate(
	void * _Ptr, unsigned __int64 _Count, 
	unsigned __int64 _Sz)
Physics_Output_Suite_DLL.dll!
	std::vector<int,std::allocator<int> >::_Tidy()
Physics_Output_Suite_DLL.dll!
	`dynamic atexit destructor for 'DPSetupStatus''()
	+ 0x19 bytes	C++
ucrtbase.dll!<lambda_f03950bc5685219e0bcd2087efbe011e>::
	operator()()  + 0xa6 bytes	
ucrtbase.dll!__crt_seh_guarded_call<int>::operator()
	<<lambda_7777bce6b2f8c936911f934f8298dc43>,
	<lambda_f03950bc5685219e0bcd2087efbe011e> &,
	<lambda_3883c3dff614d5e0c5f61bb1ac94921c> >()
ucrtbase.dll!_execute_onexit_table()  + 0x34 bytes	
Physics_Output_Suite_DLL.dll!
	dllmain_crt_process_detach(const bool is_terminating)
Physics_Output_Suite_DLL.dll!
	dllmain_dispatch(HINSTANCE__ * const instance, 
	const unsigned long reason, void * const reserved)

Based on the call to NS_FaultTolerantHeap::APIHook_RtlFreeHeap()
I think the application is still using fault tolerant heap. I have verified that the vector being cleaned up is not itself corrupt (the inner pointer passed to Deallocate has the same value as it originally did). I don't see how this vector could possibly have been cleaned up twice, since it is a static global variable and it would only get cleaned up once when the DLL unloads.

Here are the steps I've tried to use to turn off fault tolerant heap:

1. I've stopped and disabled the Diagnostic Policy Service
2. In the registry, I set HKEY_LOCAL_MACHINE\SOFTWARE\

Microsoft\FTH\Enabled to 0.

1. I ran the following command as admin:

Rundll32.exe fthsvc.dll,FthSysprepSpecialize

1. I restarted my computer several times.
2. In the Event Viewer, I've verified that there's no recent activity in the Fault Tolerance Heap event log (under Applications and Services / Microsoft / Windows).

Is there some other service that would use the fault tolerant heap API? What else should I be doing to troubleshoot?

Answer 1

Heap corruption issues can be quite challenging to diagnose and resolve. It seems like you have already taken some steps to disable the Fault Tolerant Heap (FTH) but are still experiencing crashes related to heap corruption. Here are a few suggestions for further troubleshooting:

1. Check for other dependencies: Verify if any other DLLs or components in your application are using FTH. It's possible that another component is triggering the fault tolerant heap, leading to the heap corruption. Review the dependencies and investigate if any of them have FTH enabled.
2. Review your code for potential issues: Examine your codebase for any potential memory-related bugs or incorrect memory management practices that could lead to heap corruption. This includes checking for buffer overflows, uninitialized variables, use-after-free, double-free, or other memory access issues.
3. Enable debug options: Enable debugging options in your development environment and build the DLL with debug symbols. This will provide more detailed information about the crash, including memory addresses and call stack information, which can help pinpoint the source of the problem.
4. Use memory analysis tools: Utilize memory analysis tools such as Valgrind (for Linux) or Application Verifier (for Windows) to detect memory-related issues. These tools can help identify memory leaks, buffer overflows, and other memory errors that might be causing heap corruption.
5. Perform code review and testing: Review the code thoroughly, paying attention to areas that deal with memory management, especially in the context of global variables and static objects. Consider running extensive tests and stress tests to reproduce the issue consistently and narrow down its cause.
6. Consult the community or experts: Seek help from relevant developer communities, forums, or online platforms where experienced developers can provide insights or guidance on similar issues. They might have encountered similar problems and can offer suggestions specific to your programming language, environment, or libraries.

Remember that troubleshooting heap corruption issues can be a complex process. It often requires a combination of techniques, including code analysis, debugging, and testing, to identify and resolve the underlying problem.