bugs, Access Violation in msvbvm60!BoundTerminate

Spradically I'm getting an Access Violation in msvbvm60, when closing
our application whose executable is made with VB6.

Questions:
# Did anyone see similar behaviour somewere else?
# Can anyone point me were to look deeper into?

Here is the excerpt of a dump analysis:

0:000> !analyze -v
[...]
EXCEPTION_RECORD: 0012f704 -- (.exr 12f704)
ExceptionAddress: 660a2b9a (msvbvm60!BoundTerminate+0x0000001a)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 03151c02
Attempt to read from address 03151c02

STACK_TEXT:
0012fa14 6608b22d 07479e14 0747a104 0747a265
msvbvm60!BoundTerminate+0x1a
0012fa24 6604b202 07430ef4 00000001 00000002
msvbvm60!DESKOLE::Close+0x2e
0012fa40 6604677b 00000001 0747a104 660467c6
msvbvm60!COcx::CloseServer+0x62
0012fa4c 660467c6 00000001 00000000 0000105c
msvbvm60!COcx::TransitionDown+0x5c
0012fa60 66045dcd 00000001 00000000 0000105c
msvbvm60!COcx::TransitionTo+0x36
0012fac8 66049ccc 08000000 0747a104 00120d86
msvbvm60!COcx::DiscardObject+0x28
0012faf8 6605b4b1 0747a104 00120d86 0000105c
msvbvm60!COcx::CtlProc+0x407
0012fb28 6601c56a 0741d928 00000000 0745d56c
msvbvm60!CCreDestroyCtl+0x175
0012fb6c 6601d752 00150b88 00000000 00000001
msvbvm60!CCreFUnloadForm+0x1c9
0012fb8c 66093965 0743c94c 00e01e94 00e48924
msvbvm60!DestroyAllDesks+0x63
0012fb9c 6601e85a 00e01fa4 00e48924 00000000
msvbvm60!CleanupUIThreadData+0x1b
0012fbb8 660729bd 073e690c 00000001 00000000
msvbvm60!CVBThreadAction::CleanupProjData+0x81
0012fbc8 6601d6e5 00e48924 0012fcb0 00000000
msvbvm60!CThreadPool::CleanupAtDllDetach+0x14
0012fbec 660061b5 0012fcb0 66006041 00000000
msvbvm60!EndMainProgram+0xb9
0012fc28 6600605a 073e690c 000f0096 00001050
msvbvm60!FnwpMainFilter+0x5b3
0012fc48 77d48734 000f0096 00001050 00000000 msvbvm60!FnwpMain+0x19
0012fc74 77d48816 66006041 000f0096 00001050
user32!InternalCallWinProc+0x28
0012fcdc 77d4b4c0 00000000 66006041 000f0096
user32!UserCallWinProcCheckWow+0x150
0012fd30 77d4b50c 007d32c8 00001050 00000000
user32!DispatchClientMessage+0xa3
0012fd58 7c90eae3 0012fd68 00000018 007d32c8 user32!__fnDWORD+0x24
0012fd7c 77d494be 77d4d890 000f0096 00001050
ntdll!KiUserCallbackDispatcher+0x13
0012fdb8 77d5f3e3 007d32c8 00001050 00000000
user32!NtUserMessageCall+0xc
0012fdd8 6600b36d 000f0096 00001050 00000000 user32!SendMessageA+0x7f
0012fdfc 6600a7aa 00e03834 00e0375c 77d489cd
msvbvm60!ModeFinishReset+0x78
0012fe2c 6600a737 ffffffff 000008b8 6600a711
msvbvm60!MainAfterDispatch+0xee
0012fe38 6600a711 00e037fc ffffffff 000008b8
msvbvm60!CMsoComponent::FContinueMessageLoop+0xd
0012fe6c 6600a6bd 00000000 6600a4aa 00e03764
msvbvm60!SCM::FContinueMessageLoop+0x49
0012fe74 6600a4aa 00e03764 00000000 ffffffff
msvbvm60!SCM_MsoStdCompMgr::FContinueMessageLoop+0x10
0012feb8 6600a41a ffffffff 00e03764 00e00000
msvbvm60!ThunderMsgLoop+0x104
0012fecc 6600a3bc 00e0373c ffffffff 00e03834
msvbvm60!CMsoCMHandler::FPushMessageLoop+0x19
0012fefc 6600a2f8 00e03834 ffffffff 000008b8
msvbvm60!SCM::FPushMessageLoop+0xb9
0012ff18 6600a2c3 00e03760 00e03834 ffffffff
msvbvm60!SCM_MsoCompMgr::FPushMessageLoop+0x2b
0012ff3c 6600361c ffffffff 000f0df8 03c1f1b0
msvbvm60!CMsoComponent::PushMsgLoop+0x26
0012ffb8 00403f26 00404580 7c816d4f 000f0df8 msvbvm60!ThunRTMain+0x9b
0012fff0 00000000 00403f1c 00000000 78746341 2100_expert!__vbaS+0xa


FOLLOWUP_IP:
msvbvm60!BoundTerminate+1a
660a2b9a f6402a40 test byte ptr [eax+2Ah],40h

0:000> lmvm msvbvm60
start end module name
66000000 66152000 msvbvm60 (pdb symbols)
[...]\MSVBVM60.pdb
Loaded symbol image file: [...]msvbvm60.dbg
Image path: C:\WINDOWS\system32\msvbvm60.dll
Image name: msvbvm60.dll
Timestamp: Tue Feb 24 05:15:40 2004 (403ACFEC)
[...]
File version: 6.0.97.82

f you are using XPSP2 or have recently updated the MDAC or other MS
products you may to change out the version of msvbvm60 that is on the target
machine.

But I would investigate and insure that all objects are cleaned up before
messing with msvbm60 versioning.

Google this newsgroup and ...
microsoft.public.vb.general.discussion
microsoft.public.vb.enterprise
for numerous examples of msvbvm60 and WinXP problems.

hth
-ralph


< XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

i Ralph,

thanks a lot for the hint. I think, it is not a good idea to 'rollback'
to some older version of MSVBVM. If I knew what happens in
msvbvm60!BoundTerminate, I could oracle what I could change in the
application code.
Unfortunately this error occured only once and I don't know how to
reproduce.

Anyways, thanks,
Volker

Ralph wrote:

<snipped>

Agree. Such fixes should be reserved for cases where something always
breaks. <g>

However, the ability to just 'code' around some intermittent issues is often
more difficult that assumed. With the introduction of Data Access objects we
have been lulled into thinking there are only 3 or 4 layers between a line
of code and the data, and that the 'code' is in charge. Unfortunately there
are actually something more like 15 to 20+ layers (and an equal number of
components) between here and there, and back again.

The fact that any new component works well with everything already there is
more miracle than a certainty. <g>

-ralph

Oh, you're right... let's believe in miracles ;-)

lt; XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


Did you use "Remove Array Bound Checks" in the project's properties?

o, I didn't. In such a case I would suspect to get the crash in the
production code and not at the end. I think the crash was related to
the usage of SetUnhandledExceptionFilter. I set it to a new address and
reset it to 0 and not to the address previously defined (returned by
the first call to that API).

expvb wrote: