Occasional Program Error.
Larry
2003. Now about every 12th to 13th time I run it in debug mode I get a
"Unhandled exception at 0x7c901230" error. in visual studio. To try and get
more info on the error I'm running windbg. When I get the error when
starting the application if I continue I also get an error on exit.
Can anyone help me with these errors below?
Thanks Larry
The initial message that comes up in windbg:
HEAP[fseries.exe]: HEAP: Free Heap block 125be50 modified at 125bea0 after
it was freed
(86c.ef8): Break instruction exception - code 80000003 (first chance)
eax=0125be50 ebx=00000040 ecx=7c91eb05 edx=0012e74c esi=0125be50 edi=00000138
eip=7c901230 esp=0012e94c ebp=0012e950 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
DBGHELP: ntdll - public symbols
C:\WINDOWS\system32\ntdll.pdb
ntdll!DbgBreakPoint:
7c901230 cc int 3
The error message on exit:
WinHelp: pszHelpFile = 'X:\MyProjects\FSERIES RTC3\Debug\fseries.HLP',
dwData: $0, fuCommand: 2.
(86c.ef8): Break instruction exception - code 80000003 (first chance)
eax=00000001 ebx=7ffdd000 ecx=0012f7ac edx=7c90eb94 esi=00e6fa9c edi=00080000
eip=0040718f esp=0012f7fc ebp=0012f85c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
*** WARNING: Unable to verify checksum for fseries.exe
DBGHELP: fseries - private symbols & lines
X:\MyProjects\FSERIES RTC3\Debug\fseries.pdb
fseries!CBaseThread::bStopRunningThread+0x9f:
0040718f cc int 3
The Call stack for exit error:
0:000> kb
ChildEBP RetAddr Args to Child
0012f85c 0041329a 00000063 00080000 00e6fa9c
fseries!CBaseThread::bStopRunningThread+0x9f [x:\myprojects\fseries
rtc3\source\basethread.cpp @ 115]
0012f8c8 00413224 00080000 00e6fa9c 7ffdd000
fseries!GALVO_THREAD::~GALVO_THREAD+0x4a [x:\myprojects\fseries
rtc3\source\galvo_thread.cpp @ 78]
0012f920 0040e751 00000001 00080000 00e6fa9c fseries!GALVO_THREAD::`scalar
deleting destructor'+0x14
0012fa0c 0040db28 00080000 00e6fa9c 7ffdd000
fseries!CFseriesDlg::~CFseriesDlg+0x511 [x:\myprojects\fseries
rtc3\source\fseriesdlg.cpp @ 174]
0012fed0 7c235a67 7c97e4c0 7c8021b5 7c802011
fseries!CFseriesApp::InitInstance+0x348 [x:\myprojects\fseries
rtc3\source\fseries.cpp @ 153]
0012fef4 0046dca8 00400000 00000000 00141f0e MFC71D!AfxWinMain+0x77
0012ff0c 00466292 00400000 00000000 00141f0e fseries!WinMain+0x18
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\src\mfc\appmodul.cpp @ 25]
0012ffc0 7c816d4f 00080000 00e6fa9c 7ffdd000 fseries!WinMainCRTStartup+0x1f2
[f:\vs70builds\3077\vc\crtbld\crt\src\crtexe.c @ 390]
0012fff0 00000000 004660a0 00000000 78746341 kernel32!BaseProcessStart+0x23
Ivan Brugiolo [MSFT]
The best approach would be to run your application with the `full pageheap`
instrumentation
c:\debuggers> gflags -p /enable fseries.exe /full
and, when a problem is detected, run `!heap -p -a <address>`.
Assuming this is a simple reuse-after-delete, the debugger
should give the stack trace of whomever has free-ed the block.
From the few lines below, the recomended steps would be to
dump the content of the memory block that has triggered the heap
breakpoints,
for example, with "dc 125be50-8 125bea0", and see if the stomped-on value
resembles any pattern, constant of value familiar to the code being
executed.
The second problem seems some form of hard-coded breakpoint.
Source code inspection of CBaseThread::bStopRunningThread
should clear that out.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Larry" <La...@discussions.microsoft.com> wrote in message
news:544F005D-D2E4-4FA7...@microsoft.com...
Larry
From the CMD window:
gflags -p /enable X:\MyProjects\FSERIES RTC3\Debug\fseries.exe
/fullug\fseries.exe /full
windbg -g -G
Once I get the error in Windbg I tried the ! heap command and I got an error:
HEAP[fseries.exe]: HEAP: Free Heap block 13707e8 modified at 1370838 after
it was freed
(e0.f20): Break instruction exception - code 80000003 (first chance)
eax=013707e8 ebx=00000040 ecx=7c91eb05 edx=0012e588 esi=013707e8 edi=00000338
eip=7c901230 esp=0012e788 ebp=0012e78c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3
0:000> !heap -p -a 13707e8
**********************************************
the `!heap -p' commands in exts.dll have been replaced
with equivalent commands in ext.dll.
If your are in a KD session, use `!ext.heap -p`
**********************************************
Thanks
Larry
Ivan Brugiolo [MSFT]
You cannot specify the full path to gflags.exe, only the image name.
If page-heap is enabled, a convenient message will be spewed to the
debugger.
#2
You probably are using unsupported ntsd.exe from the OS instead
of the one coming from the debugger package
You should be able to use `!ext.heap -p -a <address>` if the extension
is not alread in the output of `.chain`
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Larry" <La...@discussions.microsoft.com> wrote in message
news:81443175-DD1C-405E...@microsoft.com...
Larry
create a new instance of a thread class. In the constructor I initialize
several CStrings. The visual studio debugger was stopping in the malloc.c
file and the call stack would take me to a spot where I was initializing a
string. Not always the same thread.
Your Thoughts?
Larry
Windbg command info:
0:000> !ext.heap -p -a 13707e8
address 013707e8 found in
_HEAP @ bd0000
in HEAP_ENTRY: Size : Prev Flags - UserPtr UserSize - state
13707e8: 0069 : N/A [N/A] - 13707f0 (340) - (free)
0:000> !ext.heap -p -a 1370838
address 01370838 found in
_HEAP @ bd0000
in HEAP_ENTRY: Size : Prev Flags - UserPtr UserSize - state
13707e8: 0069 : N/A [N/A] - 13707f0 (340) - (free)
0:000> dc 13707e8-8 1370838
013707e0 00000000 00000000 005c0069 01180492 ........i.\.....
013707f0 00bd04c0 00bd04c0 feeefeee feeefeee ................
01370800 feeefeee feeefeee feeefeee feeefeee ................
01370810 feeefeee feeefeee feeefeee feeefeee ................
01370820 feeefeee feeefeee feeefeee feeefeee ................
01370830 feeefeee feeefeee 00000000 ............
*** WARNING: Unable to verify checksum for fseries.exe
Windbg call stack:
ntdll!DbgBreakPoint
ntdll!RtlpBreakPointHeap+0x28
ntdll!RtlAllocateHeapSlowly+0x7c4
ntdll!RtlDebugAllocateHeap+0xaf
ntdll!RtlAllocateHeapSlowly+0x44
ntdll!RtlAllocateHeap+0xe64
MSVCR71D!_heap_alloc_base+0x145
[f:\vs70builds\3077\vc\crtbld\crt\src\malloc.c @ 212]
MSVCR71D!_heap_alloc_dbg+0x1af
[f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c @ 397]
MSVCR71D!_nh_malloc_dbg+0x49 [f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c
@ 260]
MSVCR71D!malloc+0x19 [f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c @ 139]
MFC71D!CAfxStringMgr::Allocate+0x65
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\src\mfc\strcore.cpp @ 141]
MFC71D!ATL::CSimpleStringT<char,1>::Fork+0x3f
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\include\atlsimpstr.h @ 718]
MFC71D!ATL::CSimpleStringT<char,1>::PrepareWrite2+0x43
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\include\atlsimpstr.h @ 756]
MFC71D!ATL::CSimpleStringT<char,1>::PrepareWrite+0x42
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\include\atlsimpstr.h @ 743]
MFC71D!ATL::CSimpleStringT<char,1>::GetBuffer+0x13
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\include\atlsimpstr.h @ 491]
MFC71D!ATL::CSimpleStringT<char,1>::SetString+0x50
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\include\atlsimpstr.h @ 604]
MFC71D!ATL::CSimpleStringT<char,1>::SetString+0x20
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\include\atlsimpstr.h @ 581]
MFC71D!ATL::CSimpleStringT<char,1>::operator=+0x13
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\include\atlsimpstr.h @ 318]
MFC71D!ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >
>::operator=+0x13
[f:\vs70builds\3077\vc\mfcatl\ship\atlmfc\include\cstringt.h @ 985]
fseries!LASER_THREAD::LASER_THREAD+0x204 [x:\myprojects\fseries
rtc3\source\laser_thread.cpp @ 53]
Lines 52 and 53 of laser_thread.cpp
for(int i=0;i<4;i++)
csShapeName[i]="none";
Ivan Brugiolo [MSFT]
of the C-Runtime that is known to interfear with PageHeap.
The only thing I can spot is a dword with zero where the fill pattern should
be.
However, due to the issues above, the instrumentation is not active,
and not able to pinpoint the place where the reuse-after-delete has
happened.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Larry" <La...@discussions.microsoft.com> wrote in message
news:10A98490-5C1D-45A4...@microsoft.com...
Larry
the release by itself I get no errors. With Windbg I get a different error
message than before, see below.
Again thanks for you help an patience, problems this deep are new to me.
Larry
ModLoad: 605d0000 605d9000 C:\WINDOWS\system32\mslbui.dll
(664.e70): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=07576fb8 ebx=ffffffff ecx=0012f3e4 edx=7c90eb94 esi=074be7a0 edi=00000000
eip=004117e2 esp=0012f3d4 ebp=074be7a8 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
Unable to load image image00400000, Win32 error 2
*** WARNING: Unable to verify checksum for image00400000
*** ERROR: Module load completed but symbols could not be loaded for
image00400000
image00400000+0x117e2:
004117e2 897828 mov [eax+0x28],edi ds:0023:07576fe0=????????
Ivan Brugiolo [MSFT]
Please run `!heap -p -a 07576fe0`,
and the debugger should tell you which block freed the memory
that the code below is touching.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Larry" <La...@discussions.microsoft.com> wrote in message
news:1DAACBF1-53B3-4F5B...@microsoft.com...
Larry
Larry
0:000> !ext.heap -p -a 07576fe0
address 07576fe0 found in
_DPH_HEAP_ROOT @ 20c1000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr
VirtSize)
6f97520: 7576000 2000
7c9268ad ntdll!RtlFreeHeap+0x000000f9
7c34218a MSVCR71!free+0x000000c3
7c15112c MFC71!CWinThread::`scalar deleting destructor'+0x00000015
7c349565 MSVCR71!_threadstartex+0x0000006f
7c80b50b kernel32!BaseThreadStart+0x00000037
0:000> !ext.heap -p
Active GlobalFlag bits:
hpa - Place heap allocations at ends of pages
StackTraceDataBase @ 004b0000 of size 01000000 with 00000e32 traces
PageHeap enabled with options:
ENABLE_PAGE_HEAP
COLLECT_STACK_TRACES
active heaps:
+ 140000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 240000
HEAP_GROWABLE
+ 14b0000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 350000
HEAP_GROWABLE HEAP_CLASS_1
+ 1b70000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 1c70000
HEAP_GROWABLE HEAP_CLASS_1
+ 1e90000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 1f90000
HEAP_GROWABLE HEAP_CLASS_1
+ 20c0000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 21c0000
HEAP_GROWABLE HEAP_CLASS_1
+ 2500000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 2600000
HEAP_GROWABLE HEAP_CLASS_1
+ 3a70000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 3b70000
HEAP_GROWABLE HEAP_CLASS_1
+ 3bb0000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 3cb0000
HEAP_GROWABLE HEAP_CLASS_1
+ 63a0000
ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
NormalHeap - 4360000
HEAP_GROWABLE HEAP_CLASS_1
Ivan Brugiolo [MSFT]
after it was free-ed in the location indicated by the call stack below.
This is a reuse-after-delete case of heap corruption.
The object seems to be an instance CWinThread.
Now, I'm not familiar with the general lifetime management policy
of that object in your code, but, per code inspection, and with the help
of the stack of the location of the free operation and the location
where your code currently crashes, you should be able to figure that out.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Larry" <La...@discussions.microsoft.com> wrote in message
news:7536740F-EC35-4167...@microsoft.com...
Larry
How bad is heap corruption?
I've never had a release build crash only the debug, Why?
Has then always been a problem and the VS .net is finding it where vs 6.0
did not?
Or could it be a new problem because I changed to .net?
Again Thanks for all your help, much appreciated.
Larry
Skywing
memory returned to you are going to fail in unexpected ways (e.g. someone
else already has a pointer to that memory, or someone else overwrites part
of your datastructure causing crashes or other strange behavior when you try
to use that datastructure later on, or the page gets freed out from under
you, etc.)
Due to the nature of the problem the symtoms may not manifest themselves
immediately, and changes to how the CRT manages the heap between debug and
release builds may seem to hide the symtoms for some time.
In general you should strive to fix memory corruption type problems as soon
as possible as they tend to lead to unpredictable, difficult to diagnose,
and hard to reproduce failures in the future.
I would look for things like using a pointer to a heap block after you've
freed it, or writing past the end of a heap block returned to you.
"Larry" <La...@discussions.microsoft.com> wrote in message
news:399CDEBE-B7DC-4457...@microsoft.com...
Matt Adamson
Am I not missing something here but why not turn on full page heap tracking
so any heap corruption causes an AV straightaway at the point of heap
corruption..
Cheers
Matt
"Skywing" <skywing_...@valhallalegends.com> wrote in message
news:OoOKxquj...@tk2msftngp13.phx.gbl...
Skywing
already suggested this earlier on in the thread.
By "unpredictable, difficult to diagnose, and hard to reproduce failures"
I'm talking about the case where a program is released with a memory
corruption bug and then you start getting strange crash dumps from customers
in cases that 'should never' crash.
"Matt Adamson" <Adamson...@hotmail.com> wrote in message
news:emYBdxuj...@TK2MSFTNGP09.phx.gbl...
Ivan Brugiolo [MSFT]
on how to gather the proper debugging information from that.
However, the OP seems unsure about if he should fix the problem,
and how to fix it.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Matt Adamson" <Adamson...@hotmail.com> wrote in message
news:emYBdxuj...@TK2MSFTNGP09.phx.gbl...
Larry
"Ivan Brugiolo [MSFT]" wrote:
> PageHeap was indeed turned on, and, the OP was instructed
> on how to gather the proper debugging information from that.
> However, the OP seems unsure about if he should fix the problem,
> and how to fix it.
You are correct. The program has been running for years. Now I compile in
.net 2003 and I get errors. At this time I'm lost. Has the problem been
there all the time? Is it due to the changes in the MFC classes? Is it a
compiler problem? After all I did not change the way I use a my CWinThread
pointer.
My head is spinning.
Larry
Larry
windbg program on a VS 6.0 version i get the same error:
I'm not sure what I'm going do.
Larry
0:000> !ext.heap -p -a 02b8cfb8
address 02b8cfb8 found in
_DPH_HEAP_ROOT @ 1b91000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr
VirtSize)
290e9b0: 2b8c000 2000
7c9268ad ntdll!RtlFreeHeap+0x000000f9
77c2c2de msvcrt!free+0x000000c3
73e6b1f3 MFC42!CWinThread::`vector deleting destructor'+0x00000017
77c3a3b0 msvcrt!_endthreadex+0x000000a9
7c80b50b kernel32!BaseThreadStart+0x00000037
Ivan Brugiolo [MSFT]
unpredictable by definition.
You may manage to stop the application, you may end-up formatting your
customer's hard-drive.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Larry" <La...@discussions.microsoft.com> wrote in message
news:A1E92FBF-9073-4B10...@microsoft.com...