Link to home
Start Free TrialLog in
Avatar of binary_1001010
binary_1001010Flag for Singapore

asked on

help me to analyze this dump file

does this bugcheck indicate  schedule_report_060424.exe having a problem or msado15.dll is having a problem?


FAULTING_IP:
msado15!CContext::~CContext+2a
1f45e940 ff5108           call    dword ptr [ecx+0x8]

EXCEPTION_RECORD:  ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 1f45e940 (msado15!CContext::~CContext+0x0000002a)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 24448bcb
Attempt to read from address 24448bcb

FAULTING_THREAD:  00000f44

DEFAULT_BUCKET_ID:  APPLICATION_FAULT

PROCESS_NAME:  schedule_report_060424.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

READ_ADDRESS:  24448bcb

BUGCHECK_STR:  ACCESS_VIOLATION

LAST_CONTROL_TRANSFER:  from 1f452395 to 1f45e940

STACK_TEXT:  
0003b340 1f452395 00000000 03de4de8 00000000 msado15!CContext::~CContext+0x2a
0003b3cc 1f455e12 00000000 03de6160 00000003 msado15!CCommand::SetConnection+0x24f
0003b3fc 1f486de0 03de4de8 00000000 03de6160 msado15!CCommand::putref_ActiveConnection+0x3c
0003b41c 1f448a26 03de6160 00000000 00000000 msado15!CRecordset::SwapActiveConnection+0xde
0003b438 1f4428ce 03de6160 03de616c 00000001 msado15!CRecordset::Term+0x16
0003b458 1f442ace 6a9f47fe 0003be00 00000001 msado15!CStdSymbiontObject::InternalRelease+0x66
0003b468 6a9f50e6 03de6160 6aad109e 0040a524 msado15!ATL::CComObject<CCommand>::Release+0x11
0003b474 0040a524 6aad11c3 0003b490 0003be50 MSVBVM60!__vbaFreeObj+0xf
WARNING: Stack unwind information not available. Following frames may be wrong.
0003be60 00409a15 0013b140 0003bf98 0003c068 schedule_report_060424+0xa524
0003bf8c 6a9faea0 0013b140 0003bfa8 00401dc9 schedule_report_060424+0x9a15
0003bfa8 6a9fae7d 00401dc9 0003c064 00000002 MSVBVM60!CallProcWithArgs+0x1e
0003bfc0 6a9fae35 0013b268 0003c0a4 0003c064 MSVBVM60!InvokeVtblEvent+0x32
0003bfe8 6a9f308c 00000001 0003c0c8 6a9f31a4 MSVBVM60!InvokeEvent+0x42
0003c0c8 6a9f3033 00d702f4 00d6fc44 00d64f38 MSVBVM60!EvtErrFireWorker+0x41
0003c0ec 6a9ede3e 00d702f4 00000006 0003c10c MSVBVM60!EvtErrFire+0x1b
0003c148 6a9edc5d 00da1e94 00000000 00000000 MSVBVM60!CioErrLoadFormDesk+0x1b8
0003c168 6a9edc22 00da1e94 00d67adc 00000000 MSVBVM60!CioErrLoadOnlyFormDesk+0x17
0003c184 6aa5151a 00d6fc44 0003c1a0 6a9f4be1 MSVBVM60!_LoadForm+0x34
0003c1d4 0040a445 00d69444 004028e0 0013b140 MSVBVM60!RefEnsureCtlMapEntLoaded+0x3b
0003c2c8 00409a15 0013b140 0003c400 0003c4d0 schedule_report_060424+0xa445
0003c3f4 6a9faea0 0013b140 0003c410 00401dc9 schedule_report_060424+0x9a15
0003c410 6a9fae7d 00401dc9 0003c4cc 00000002 MSVBVM60!CallProcWithArgs+0x1e
0003c428 6a9fae35 0013b268 0003c50c 0003c4cc MSVBVM60!InvokeVtblEvent+0x32
0003c450 6a9f308c 00000001 0003c530 6a9f31a4 MSVBVM60!InvokeEvent+0x42
0003c530 6a9f3033 00d702f4 00d6fc44 00d64f38 MSVBVM60!EvtErrFireWorker+0x41
0003c554 6a9ede3e 00d702f4 00000006 0003c574 MSVBVM60!EvtErrFire+0x1b
0003c5b0 6a9edc5d 00da1e94 00000000 00000000 MSVBVM60!CioErrLoadFormDesk+0x1b8
0003c5d0 6a9edc22 00da1e94 00d67adc 00000000 MSVBVM60!CioErrLoadOnlyFormDesk+0x17
0003c5ec 6aa5151a 00d6fc44 0003c608 6a9f4be1 MSVBVM60!_LoadForm+0x34
0003c63c 0040a445 00d69444 004028e0 0013b140 MSVBVM60!RefEnsureCtlMapEntLoaded+0x3b
0003c730 00409a15 0013b140 0003c868 0003c938 schedule_report_060424+0xa445
0003c85c 6a9faea0 0013b140 0003c878 00401dc9 schedule_report_060424+0x9a15
0003c878 6a9fae7d 00401dc9 0003c934 00000002 MSVBVM60!CallProcWithArgs+0x1e
0003c890 6a9fae35 0013b268 0003c974 0003c934 MSVBVM60!InvokeVtblEvent+0x32
0003c8b8 6a9f308c 00000001 0003c998 6a9f31a4 MSVBVM60!InvokeEvent+0x42
0003c998 6a9f3033 00d702f4 00d6fc44 00d64f38 MSVBVM60!EvtErrFireWorker+0x41
0003c9bc 6a9ede3e 00d702f4 00000006 0003c9dc MSVBVM60!EvtErrFire+0x1b
0003ca18 6a9edc5d 00da1e94 00000000 00000000 MSVBVM60!CioErrLoadFormDesk+0x1b8
0003ca38 6a9edc22 00da1e94 00d67adc 00000000 MSVBVM60!CioErrLoadOnlyFormDesk+0x17
0003ca54 6aa5151a 00d6fc44 0003ca70 6a9f4be1 MSVBVM60!_LoadForm+0x34
0003caa4 0040a445 00d69444 004028e0 0013b140 MSVBVM60!RefEnsureCtlMapEntLoaded+0x3b
0003cb98 00409a15 0013b140 0003ccd0 0003cda0 schedule_report_060424+0xa445
0003ccc4 6a9faea0 0013b140 0003cce0 00401dc9 schedule_report_060424+0x9a15
0003cce0 6a9fae7d 00401dc9 0003cd9c 00000002 MSVBVM60!CallProcWithArgs+0x1e
0003ccf8 6a9fae35 0013b268 0003cddc 0003cd9c MSVBVM60!InvokeVtblEvent+0x32
0003cd20 6a9f308c 00000001 0003ce00 6a9f31a4 MSVBVM60!InvokeEvent+0x42
0003ce00 6a9f3033 00d702f4 00d6fc44 00d64f38 MSVBVM60!EvtErrFireWorker+0x41
0003ce24 6a9ede3e 00d702f4 00000006 0003ce44 MSVBVM60!EvtErrFire+0x1b
0003ce80 6a9edc5d 00da1e94 00000000 00000000 MSVBVM60!CioErrLoadFormDesk+0x1b8
0003cea0 6a9edc22 00da1e94 00d67adc 00000000 MSVBVM60!CioErrLoadOnlyFormDesk+0x17


FOLLOWUP_IP:
msado15!CContext::~CContext+2a
1f45e940 ff5108           call    dword ptr [ecx+0x8]

SYMBOL_STACK_INDEX:  0

FOLLOWUP_NAME:  MachineOwner

SYMBOL_NAME:  msado15!CContext::~CContext+2a

MODULE_NAME:  msado15

IMAGE_NAME:  msado15.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  3c9fa76d

STACK_COMMAND:  ~0s ; kb

FAILURE_BUCKET_ID:  ACCESS_VIOLATION_msado15!CContext::~CContext+2a

BUCKET_ID:  ACCESS_VIOLATION_msado15!CContext::~CContext+2a

Followup: MachineOwner
ASKER CERTIFIED SOLUTION
Avatar of GinEric
GinEric

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of binary_1001010

ASKER

Thanks GinEric, am I right to say msado15.dll is not an issue here?

BTW, where do you learn all these stuff?  Very cool.

Thanks again.
Avatar of GinEric
GinEric

I'm an Electrical Engineer who has designed the mainframes these computers are all based on.  [since you asked where I learned all this stuff]  And I constantly read up on everything that comes out, and constantly upgrade my hands on experience.

I don't really know if msado15.dll is affecting this, but the MicroSoft Data Access Objects Dynamic Link Library may hit a snag as best described here:

http://dbforums.com/t346916.html

which suggests it's a bug in Access itself that causes a problem when a vector indirect reference is called [double-indexing] and the hardware works too fast; a common problem in drivers moving from 32-bit to 64-bit world in Windows and Linux.