Meaning of exception 0xC0000006 (EXCEPTION_IN_PAGE_ERROR)
Rob Yampolsky
to crash. From the descriptions on MSDN (included below), it seems to
me that this is a LAN connectivity problem. My interpretation of the
description is that the app was run from an .exe on a LAN drive, and
somewhere along the line a page fault caused Windows to attempt to load
another page of the .exe, and the LAN drive was inaccessible.
Is this explanation 100% accurate? In other words, can I be sure that
this is not being caused by a bug in the application? Does 'access a
page that wasn't present' specifically refer to a page of the
application, or could this also refer to heap or stack pages? Either
way, would it be possible for a bug in the app to be causing the
ECEPTION_IN_PAGE_ERROR's?
The client has recently gotten an upgrade to this application, but they
have also recently reconfigured their LAN for their accounting
department, which happen to be the only users experiencing this problem
- other users use the app without the problem.
They're screaming, and I need to be able to tell them definitively that
this is a problem with their LAN. Otherwise they will continue to
assume it's my problem and drive me nuts.
Am I right?
Thanks,
Rob
EXCEPTION_IN_PAGE_ERROR
The thread tried to access a page that was not present, and the system
was unable to load the page. -ie. the program or memory mapped file
couldn't be paged in because it isn't accessable any more. Device
drivers can return this exception if something went wrong with the read
(i.e hardware problems)
EXCEPTION_IN_PAGE_ERROR
The thread tried to access a page that was not present, and the system
was unable to load the page. For example, this exception might occur if
a network connection is lost while running a program over the network.
Rob Yampolsky
Fault". In other words, have I trashed the stack, and received this
exception when I tried to 'return' to an invalid address?
If so, the documentation's plenty misleading. I mean, I guess a
hardware problem could cause it too, but if it's just referring to an
unmapped page, then a corrupted pointer's a more likely candidate, no?
Rob
Stephen Kellett
<m...@nospam.org> writes
>...Or, is EXCEPTION_IN_PAGE_ERROR just another way to say "Segmentation
>Fault".
No.
>In other words, have I trashed the stack, and received this exception
>when I tried to 'return' to an invalid address?
Think of EXCEPTION_ACCESS_VIOLATION as being roughly equivalent to
Segmentation Fault.
Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html
Rob Yampolsky
> Think of EXCEPTION_ACCESS_VIOLATION as being roughly equivalent to
> Segmentation Fault.
>
Does that mean that my client's EXCEPTION_IN_PAGE_ERROR's are definitely
*not* caused by stack corruption and truly are a hardware (or LAN
connectivity) problem as the documentation seems to imply?
As a test, we've had the client put a copy of the .exe on their C:
drive, and they're still getting the same crashes...
Rob.
Stephen Kellett
<m...@nospam.org> writes
>Does that mean that my client's EXCEPTION_IN_PAGE_ERROR's are
>definitely *not* caused by stack corruption and truly are a hardware
>(or LAN connectivity) problem as the documentation seems to imply?
No idea. I would think unlikely. Why do you think it is stack
corruption?
Joe Greer
handle. The 0xC at the beginning just flags this as a severe error. See
winerror.h for explanation of bits.
joe
"Rob Yampolsky" <m...@nospam.org> wrote in message
news:u9kIb4cP...@TK2MSFTNGP11.phx.gbl...
Pavel Lebedinsky
application could cause a STATUS_IN_PAGE_ERROR.
Do you have a DrWatson crash dump? Or better yet, can you
reproduce the problem under a debugger such as windbg?
"Rob Yampolsky" <m...@nospam.org> wrote...
Rob Yampolsky
> I think if far more likely that this is really error 6, which is Invalid
> handle. The 0xC at the beginning just flags this as a severe error. See
> winerror.h for explanation of bits.
The only reason I'm assuming it's EXCEPTION_IN_PAGE_ERROR is that Dr.
Watson says it is. This value is not coming from 'errno', which is
where I'd expect to see 'Invalid Handle' errors. This is an unhandled
exception error that's being trapped by Dr. Watson.
Also, the examples of these errors that I have occurred either on the
first instruction of a function or on the return from a window proc. No
handles involved at that point.
The fact that both failures were on stack operations made me think it
was possibly being caused by stack corruption, but others on this site
have assured me that that would not produce an IN_PAGE_ERROR.
Finally, this started happening when the client reorganized their LAN.
Rob
Rob Yampolsky
>
> No idea. I would think unlikely. Why do you think it is stack corruption?
>
I don't. I just don't want to leap to the conclusion that this is 'not
my problem' and get embarrassed later if it turns out to be.
Becuase the exception is occurring in 2 places (in 2 different apps),
one of which is on the push at the start of a function and the other is
on the return from a function (window proc of a custom control), I
thought the only likely non-hardware cause would be stack corruption.
And I did find the documentation a little vague. Presumably a bad
return address is likely to cause a page fault, and if the address is
bad, I couldn't tell from the docs whether the resulting exception would
be layed on the paging operation or the addressing violation.
Anyway, it's happening repeatedly at the same places in the code (though
it's not reliably reproduceable, and there's no consistent user behavior
that triggers it), which makes me curious about it being purely a
hardware page swapping thing.
Finally, there is anecdotal evidence that this tends to happen after
they've had the program minimized for a while and then go back to it.
Or alternately that it happens after leaving the program up overnight
and then accessing it in the morning. That might suggest a page
swapping error, so I'm 'hopeful' that it really *is not* my bug.
We're running experiments now with loading the .exe from the C: drive,
and it seems to be happening less often. I also sent out a (slightly
different) version with an exception trap in the failing window proc.
That version (also running from the C: drive) hasn't had any errors
reported yet.
Thanks,
Rob
Rob Yampolsky
> I can't think of a way a memory corrupting bug in the
> application could cause a STATUS_IN_PAGE_ERROR.
>
> Do you have a DrWatson crash dump? Or better yet, can you
> reproduce the problem under a debugger such as windbg?
Yes, I do have a DrWatson dump? That's where I'm getting the exception
code and failure address from. Haven't figured out how to use windbg to
debug this remotely. This is the first remotely reported bug that I
haven't been able to reproduce locally. Have VS6.0 on my machine along
with NuMega BoundsChecker, which reports no bad memory accesses - for
what that's worth.
In case it tells you anything useful, here's a sample of one of the
crashes courtesy of DrWatson. A Google search turned up a comment that
the ???'s reported at the failure point support the notion that the page
was unreadable at the time:
Application exception occurred:
App: (pid=976)
When: 5/19/2004 @ 09:05:36.480
Exception number: c0000006 (in page io error)
*----> System Information <----*
Computer Name: RLEENS00
User Name: RLeens
Number of Processors: 1
Processor Type: x86 Family 6 Model 8 Stepping 6
Windows 2000 Version: 5.0
Current Build: 2195
Service Pack: 2
Current Type: Uniprocessor Free
Registered Organization: Active International
Registered Owner: Active User
*----> Task List <----*
0 Idle.exe
8 System.exe
140 SMSS.exe
164 CSRSS.exe
184 WINLOGON.exe
212 SERVICES.exe
224 LSASS.exe
388 svchost.exe
416 SPOOLSV.exe
496 svchost.exe
524 mnmsrvc.exe
548 regsvc.exe
564 mstask.exe
592 suss.exe
644 WinMgmt.exe
1164 explorer.exe
904 NsCatCom.exe
468 IEXPLORE.exe
820 OUTLOOK.exe
380 MAPISP32.exe
976 wem.exe
1108 DRWTSN32.exe
0 _Total.exe
(00400000 - 004B6000)
(77F80000 - 77FFB000)
(77E80000 - 77F35000)
(77E10000 - 77E74000)
(77F40000 - 77F7C000)
(76B30000 - 76B6E000)
(70BD0000 - 70C1C000)
(77DB0000 - 77E0B000)
(77D30000 - 77D9E000)
(71700000 - 7178A000)
(782F0000 - 78532000)
(78000000 - 78046000)
(75050000 - 75058000)
(75030000 - 75043000)
(75020000 - 75028000)
(785C0000 - 785CC000)
(77980000 - 779A4000)
(77340000 - 77353000)
(77520000 - 77525000)
(77320000 - 77337000)
(75150000 - 75160000)
(75170000 - 751BF000)
(77BE0000 - 77BEF000)
(751C0000 - 751C6000)
(77950000 - 77979000)
(77A50000 - 77B3C000)
(779B0000 - 77A4B000)
(773B0000 - 773DE000)
(77380000 - 773A2000)
(77830000 - 7783E000)
(77880000 - 7790D000)
(77C10000 - 77C6D000)
(774E0000 - 77512000)
(774C0000 - 774D1000)
(77530000 - 77552000)
(77360000 - 77379000)
(775A0000 - 77625000)
(777E0000 - 777E8000)
(777F0000 - 777F5000)
(74FD0000 - 74FEF000)
(75010000 - 75017000)
State Dump for Thread Id 0x3a8
eax=00000001 ebx=0049a358 ecx=01010101 edx=bb33d7e8 esi=0012e604
edi=00000000
eip=00440a4e esp=0012e2dc ebp=0012e588 iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00000202
function: <nosymbols>
00440a44 ???
00440a45 ???
00440a46 ???
00440a47 ???
00440a48 ???
00440a49 ???
00440a4a ???
00440a4b ???
00440a4c ???
00440a4d ???
FAULT ->00440a4e ???
00440a4f ???
00440a50 ???
00440a51 ???
00440a52 ???
00440a53 ???
00440a54 ???
00440a55 ???
00440a56 ???
00440a57 ???
00440a58 ???
00440a59 ???
*----> Stack Back Trace <----*
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0012E2D8 0012E604 00000000 00000000 00000000 00000000 !<nosymbols>
0012E588 77E12E98 002E0160 00000081 00000000 0012E62C <nosymbols>
0012E5A8 77E139A3 0043CD72 002E0160 00000081 00000000 user32!ScrollDC
0012E5C4 77E180C4 0056B980 00000081 00000000 0012E62C user32!GetQueueStatus
0012E5F4 77FA032F 0012E604 00000070 00000070 0000000C
user32!SendMessageCallbackW
0012E71C 77E18C31 80000000 00495688 0049A358 0012E708
ntdll!KiUserCallbackDispatcher
0012E758 00464312 00000000 00495688 0049A358 40000000
user32!CreateWindowExA
0012F348 0045DD51 001369D0 00136F58 0012F370 77E13A91 !<nosymbols>
0012F5C8 0042EEBF 001369D0 00680020 00720065 00200065 !<nosymbols>
0012FB34 0042E838 0012FB4C 0045CDD5 001400D0 00000500 !<nosymbols>
0012FB3C 0045CDD5 001400D0 00000500 0012FB58 0045CDBF !<nosymbols>
0012FB4C 0045CDBF 00000001 0012FB64 0042E2D2 00580B80 !<nosymbols>
0012FB58 0042E2D2 00580B80 0012FE34 0042AE25 000000F3 !<nosymbols>
0012FB64 0042AE25 000000F3 00000001 FFFFFFFF 00001848 !<nosymbols>
0012FE34 77E12E98 001400D0 00000500 00000180 00000001 !<nosymbols>
0012FE54 77E130E0 0042866B 001400D0 00000500 00000180 user32!ScrollDC
0012FEE0 77E15824 0012FF08 00000001 004276B5 0012FF08 user32!ScrollDC
0012FF34 0047E6FB 00400000 00000000 00133199 00000003
user32!DispatchMessageA
0012FFC0 77E97D08 00FAD450 00000000 7FFDF000 C0000006 !<nosymbols>
0012FFF0 00000000 0047E62D 00000000 000000C8 00000100
kernel32!CreateProcessW
*----> Raw Stack Dump <----*
0012e2dc 04 e6 12 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e2ec 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e2fc 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e30c 10 00 87 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e31c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e32c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e33c 00 00 00 00 e4 51 86 00 - cc 52 86 00 00 00 00 00
.....Q...R......
0012e34c 00 00 00 00 fc 6e 13 00 - 0f 00 00 00 26 41 64 64
.....n......&Add
0012e35c 20 41 66 66 69 64 61 76 - 69 74 73 00 00 00 00 00
Affidavits.....
0012e36c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e37c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e38c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e39c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 26 4c 69
.............&Li
0012e3ac 73 74 2f 43 68 61 6e 67 - 65 20 41 66 66 69 64 61 st/Change
Affida
0012e3bc 76 69 74 73 00 00 00 00 - 00 00 00 00 00 00 00 00
vits............
0012e3cc 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e3dc 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e3ec 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e3fc 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0012e40c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
Pavel Lebedinsky
was run from a network share that was later disconnected.
Since you have a crash dump you can load it in windbg
and try to get more information about why the exception
occurred.
For example, you could probably get the I/O status code
explaining why the page could not be loaded. I tried to
reproduce your problem by running notepad from a network
share then disconnecting it and forcing the system to page
out notepad's pages by running mspaint and setting image
attributes to 10000x10000. Here's what I got as a result:
(e4c.818): In-page I/O error ffffffffc000020c - code c0000006 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=c0000000 ebx=00000000 ecx=00000000 edx=007743c8 esi=01003429
edi=0006fe98
eip=01003429 esp=0006fd58 ebp=0006fd80 iopl=0 nv up ei pl nz na po
cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010207
notepad+0x3429:
01003429 ?? ???
0:000> .lastevent
Last event: e4c.818: In-page I/O error ffffffffc000020c - code c0000006
(first chance)
0:000> !error c000020c
Error code: (NTSTATUS) 0xc000020c (3221225996) - The transport connection is
now disconnected.
It would be interesting to see what status code you get
in the case where the executable is running from a
local disk.
(By the way, are you sure that in the local case you
don't have any DLLs loaded from a network share? You
can use !dlls command in windbg to see if any modules
are loaded from a network path)
"Rob Yampolsky" wrote:
> Pavel Lebedinsky wrote:
>
> > I can't think of a way a memory corrupting bug in the
> > application could cause a STATUS_IN_PAGE_ERROR.
> >
> > Do you have a DrWatson crash dump? Or better yet, can you
> > reproduce the problem under a debugger such as windbg?
>
> Yes, I do have a DrWatson dump? That's where I'm getting the exception
> code and failure address from. Haven't figured out how to use windbg to
> debug this remotely. This is the first remotely reported bug that I
> haven't been able to reproduce locally. Have VS6.0 on my machine along
> with NuMega BoundsChecker, which reports no bad memory accesses - for
> what that's worth.
>
> In case it tells you anything useful, here's a sample of one of the
> crashes courtesy of DrWatson. A Google search turned up a comment that
> the ???'s reported at the failure point support the notion that the page
> was unreadable at the time
<snip>
Rob Yampolsky
> This does look a lot like what would happen if an executable
> was run from a network share that was later disconnected.
>
> Since you have a crash dump you can load it in windbg
> and try to get more information about why the exception
> occurred.
All my client has sent me is a drwatsn32.log file. This file looks a
lot like the stuff you produced in your test, but I don't think it
counts as a 'crash dump' that windbg can handle. And if there is a
crash dump file, I'll need to take a crash course on windbg before I can
look at it. From the sound of it, that might not be a bad idea.
> (By the way, are you sure that in the local case you
> don't have any DLLs loaded from a network share? You
> can use !dlls command in windbg to see if any modules
> are loaded from a network path)
>
My app doesn't use *any* DLL's (except whatever is required by the WIN32
SDK API's, which I assume is all accessed from the C: drive).
Thanks,
Rob
Kim Gräsman
> > Since you have a crash dump you can load it in windbg
> > and try to get more information about why the exception
> > occurred.
>
> All my client has sent me is a drwatsn32.log file. This file looks a
> lot like the stuff you produced in your test, but I don't think it
> counts as a 'crash dump' that windbg can handle. And if there is a
> crash dump file, I'll need to take a crash course on windbg before I can
> look at it. From the sound of it, that might not be a bad idea.
WinDBG is always cool, but you should be able to open that dump up in VS.NET
these days. Actually, I think I read somewhere that VC6 can open dump files
as well... [1].
As long as you have matching PDBs and modules, this is a much more
comfortable experience, in my opinion.
Kim
[1] http://sairama.weblogs.us/archives/Docs/bugslayerTips.html (Tip 43..
Oh - thanks Pavel! ;))
Pavel Lebedinsky
> All my client has sent me is a drwatsn32.log file. This file looks a
> lot like the stuff you produced in your test, but I don't think it
> counts as a 'crash dump' that windbg can handle.
By default drwtsn32 should create a text log and a binary dump.
The dump is usually written to %windir%\user.dmp.
You can ask them to check if this file exists and of it does,
zip it up and send it to you.