Troubleshooting when two modules share different copy of CRT

  • Article

You may run into the problem, while upgrading from lower CRT to higher CRT version or when you mix the CRT versions. It may result in Access Violation. Here, I have used WinDbg to debug such a scenario.

Sometimes it’s hard to figure out the cause if the application access violates without displaying any error message and has following call stack.

Call Stack

=========

ChildEBP RetAddr

0012f90c 7c878921 0012f928 7c8583d8 011c4888 ntdll!DbgBreakPoint

0012f914 7c8583d8 011c4888 00c90000 011c4890 ntdll!RtlpBreakPointHeap+0x28

0012f928 7c879dbe 01220000 011c4888 7c879f64 ntdll!RtlpValidateHeapEntry+0x115

0012f990 7c85391a 01220000 50000061 011c4890 ntdll!RtlDebugFreeHeap+0x97

0012fa68 7c83e5d0 01220000 40000060 011c4890 ntdll!RtlFreeHeapSlowly+0x37

0012fb4c 78134c39 01220000 40000060 011c4890 ntdll!RtlFreeHeap+0x11a

0012f90c 7c878921 0012f928 7c8583d8 011c4888 ntdll!DbgBreakPoint

0012f914 7c8583d8 011c4888 01220000 011c4890 ntdll!RtlpBreakPointHeap+0x28

0012f928 7c879dbe 01220000 011c4888 7c879f64 ntdll!RtlpValidateHeapEntry+0x115

0012f990 7c85391a 01220000 50000061 011c4890 ntdll!RtlDebugFreeHeap+0x97

0012fa68 7c83e5d0 01220000 40000060 011c4890 ntdll!RtlFreeHeapSlowly+0x37

0012fb4c 78134c39 01220000 40000060 011c4890 ntdll!RtlFreeHeap+0x11a

0012fb98 7c422f0c 0144a6a0 00000000 00000010 MyApp!free+0x6e

-

-

-

-

From above call stack it is clear that an attempt is made to free 0x0144a6a0 from a heap whose handle is 0x01220000

Let’s find the heap from where 0x0144a6a0 is been allocated

0:063> !heap -x 0x0144a6a0

Entry User Heap Segment Size PrevSize Unused Flags

-----------------------------------------------------------------------------

0144a698 0144a6a0 00cf0000 01370000 28 28 1c busy extra fill

Here MyApp.exe depends on msvcr80.dll CRT library.

0:063> !dh MyApp –f

OPTIONAL HEADER VALUES

     10B magic #

    8.0 linker version

0:063> x msvcr80!_crtheap
72483ffc msvcr80!_crtheap = <no type information>

0:063> dd 72483ffc L4
72483ffc 00cf0000 00000000 00000000 00000000

This shows that 0x0144a6a0 is being allocated from 0x00cf0000 heap (which is CRT8.0 heap) and an attempt is made to free it in different heap 0x01220000

Call stack also shows that the ‘free‘ is called from MyApp.exe directly, this could be an evident that MyApp.exe is linking statically with CRT libraries.

There are two ways to confirm if any module is linked statically with CRT libraries

1. Run “!depends MyApp” to list the dependent libraries. There should not be any msvc*.dll in the list.

  1. Unassemble MyApp!free and there should not be any call to msvcr* components.

So the crash is because of releasing memory by MYAPP.exe which is statically linking with CRT, where as the memory being allocated by different module that is dynamically linked with CRT libraries.

To resolve this issue, link MyApp.exe with dynamic CRT libraries by selecting /MD option at Properties->C/C++->Code Generation->Runtime Library.

More information on other related issues can be found at <msdn2.microsoft.com/en-us/library/ms235460.aspx>

 

- Ravi A.

 

Developer Support VC++ and C#