Should I "EVER" get access violations?

[James Hunter Ross]

Friends, we are using ADPlus (CDB) to log w3wp.exe things are part of our
debugging efforts. A log file gets filled with TONS of "1st chance
AccessViolation" exceptions. Is this to be expected? Or, is this
indicative of some flaw that we need to fix. THings keep running, and we
never see "Second Chance", so I guess somebody is catching this stuff.

Your thoughts will be very much appreciated. Thanks in advance!

James




Mon Nov 7 09:21:14.265 2005 (GMT-8): (92c.cc4): Access violation - code
c0000005 (first chance)
---
--- 1st chance AccessViolation exception ----
---------------------------------------------------------------

Occurrence happened at:
Debug session time: Mon Nov 7 09:21:14.265 2005 (GMT-8)
System Uptime: 17 days 0:12:29.234
Process Uptime: 0 days 0:03:07.043
Kernel time: 0 days 0:00:01.593
User time: 0 days 0:00:04.562

Faulting stack below ---
# ChildEBP RetAddr Args to Child
00 0dc0f44c 792cd542 c0000005 00000000 00000002 kernel32!RaiseException+0x53
(FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be
wrong.
01 0dc0f48c 792cd586 791c97f0 0dc0f820 00000000
mscorsvr!ReleaseFusionInterfaces+0x18fea
02 0dc0f4e8 0d662d27 064a982c 0dc0f554 021a62d8
mscorsvr!ReleaseFusionInterfaces+0x1902e
03 0dc0f4ec 064a982c 0dc0f554 021a62d8 021863a8 0xd662d27
04 0dc0f4f0 0dc0f554 021a62d8 021863a8 020e8948 0x64a982c
05 0dc0f4f4 021a62d8 021863a8 020e8948 0d662acc 0xdc0f554
06 0dc0f554 0d661131 021a62d8 021863a8 020e8948 0x21a62d8
07 0dc0f59c 0cfeca7c 020e8948 021863a8 0218565c 0xd661131
08 0dc0f6cc 799a67a2 021856c4 021859c8 799b4168 0xcfeca7c
09 0dc0f6d8 799b4168 00000002 00000000 01ec14b0 mscorlib_79990000+0x167a2
0a 0dc0f760 79217188 00000000 00d83310 060d9c9c mscorlib_79990000+0x24168
0b 0dc0f794 77e6bf94 00000057 00165228 0dc0f7b0
mscorsvr!GetAssemblyMDImport+0x2e86f
0c 0dc0f7a4 77ea33b6 c000000d 0dc0f7e8 0dc0f774
kernel32!BaseSetLastNTError+0x17 (FPO: [Non-Fpo])
0d 0dc0f7b0 0dc0f774 0dc0f76c 0dc0f774 0dc0f774 kernel32!ActivateActCtx+0x2a
(FPO: [Non-Fpo])
0e 0dc0f814 791cc3c8 0dc0f884 791b3d64 0dc0f900 0xdc0f774
0f 0dc0f854 791b3e57 0dc0f8c4 7923c1c3 001650a0 mscorsvr!Ordinal76+0x1c3c8
10 0dc0f8b8 7923bcf2 0dc0ffdc 0dc0f9a8 01a3a179 mscorsvr!Ordinal76+0x3e57
11 0dc0f908 79e76329 01e9ffec 00d83310 00000000
mscorsvr!CoUninitializeEE+0x7af
12 019a3bdc 00000000 00000000 0289018b 8b04c183
aspnet_isapi!HttpCompletion:rocessRequestInManagedCode+0x17e (FPO: [Uses
EBP] [0,138,0])

 

[Bruce Barker]

yes, its probably bad. the error is occurring when asp.net is trying to
release a com obect, but the com object is blowing chuncks. its after page
processing so your pages don't see it. who knows what unmanged memory looks
like or if your leaking

-- bruce (sqlwork.com)

Friends, we are using ADPlus (CDB) to log w3wp.exe things are part of our
debugging efforts. A log file gets filled with TONS of "1st chance
AccessViolation" exceptions. Is this to be expected? Or, is this
indicative of some flaw that we need to fix. THings keep running, and we
never see "Second Chance", so I guess somebody is catching this stuff.

Your thoughts will be very much appreciated. Thanks in advance!

James




Mon Nov 7 09:21:14.265 2005 (GMT-8): (92c.cc4): Access violation - code
c0000005 (first chance)
---
--- 1st chance AccessViolation exception ----
---------------------------------------------------------------

Occurrence happened at:
Debug session time: Mon Nov 7 09:21:14.265 2005 (GMT-8)
System Uptime: 17 days 0:12:29.234
Process Uptime: 0 days 0:03:07.043
Kernel time: 0 days 0:00:01.593
User time: 0 days 0:00:04.562

Faulting stack below ---
# ChildEBP RetAddr Args to Child
00 0dc0f44c 792cd542 c0000005 00000000 00000002
kernel32!RaiseException+0x53 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be
wrong.
01 0dc0f48c 792cd586 791c97f0 0dc0f820 00000000
mscorsvr!ReleaseFusionInterfaces+0x18fea
02 0dc0f4e8 0d662d27 064a982c 0dc0f554 021a62d8
mscorsvr!ReleaseFusionInterfaces+0x1902e
03 0dc0f4ec 064a982c 0dc0f554 021a62d8 021863a8 0xd662d27
04 0dc0f4f0 0dc0f554 021a62d8 021863a8 020e8948 0x64a982c
05 0dc0f4f4 021a62d8 021863a8 020e8948 0d662acc 0xdc0f554
06 0dc0f554 0d661131 021a62d8 021863a8 020e8948 0x21a62d8
07 0dc0f59c 0cfeca7c 020e8948 021863a8 0218565c 0xd661131
08 0dc0f6cc 799a67a2 021856c4 021859c8 799b4168 0xcfeca7c
09 0dc0f6d8 799b4168 00000002 00000000 01ec14b0 mscorlib_79990000+0x167a2
0a 0dc0f760 79217188 00000000 00d83310 060d9c9c mscorlib_79990000+0x24168
0b 0dc0f794 77e6bf94 00000057 00165228 0dc0f7b0
mscorsvr!GetAssemblyMDImport+0x2e86f
0c 0dc0f7a4 77ea33b6 c000000d 0dc0f7e8 0dc0f774
kernel32!BaseSetLastNTError+0x17 (FPO: [Non-Fpo])
0d 0dc0f7b0 0dc0f774 0dc0f76c 0dc0f774 0dc0f774
kernel32!ActivateActCtx+0x2a (FPO: [Non-Fpo])
0e 0dc0f814 791cc3c8 0dc0f884 791b3d64 0dc0f900 0xdc0f774
0f 0dc0f854 791b3e57 0dc0f8c4 7923c1c3 001650a0 mscorsvr!Ordinal76+0x1c3c8
10 0dc0f8b8 7923bcf2 0dc0ffdc 0dc0f9a8 01a3a179 mscorsvr!Ordinal76+0x3e57
11 0dc0f908 79e76329 01e9ffec 00d83310 00000000
mscorsvr!CoUninitializeEE+0x7af
12 019a3bdc 00000000 00000000 0289018b 8b04c183
aspnet_isapi!HttpCompletion:rocessRequestInManagedCode+0x17e (FPO: [Uses
EBP] [0,138,0])

 

[James Hunter Ross]

Interesting. Is this true?

The developers in-house were convinced this was normal MFC-related stuff
when used in a windowless context, such as when hosted under w3wp.exe or
something.

We are having other issues related to critical sections (not our own, but
possibly ODBC or CRecordset internal ones) that don't get released, and
folks end up blocking waiting. The entire app basically stops, at least as
far as users are concerned.

Any clue on ow we meight proceed? I've been using AD-Plus (CDB) and
IISState to look at the guts of w3wp.exe after these "hangs, and these tools
have helped us rule out some things. But, these "1st chance
AccessViolation" messages might be a clue.

James

 

[Scott Allen]

I've used past version of CRecordset in a middle tier component
without problems - at least not related to the MFC stuff itself. I
think we took ATL project templates and added support for MFC
libraries.

Are you reproducing the problem in a development environment?

Can you ask the debugger to break "when the exception is thrown"
(Debug - > Exceptions dialog box) instead of breaking when an
exception goes unhandled (the default)? Just throwing out an idea.