From:	"Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Page Fault During Interupt
Date:	Tue, 25 Aug 1998 19:56:27
Organization:	Aspen Technology, Inc.
Lines:	26
Message-ID:	<35e316eb.sandmann@clio.rice.edu>
References:	<35E2B1C5 DOT 24A5 AT boat DOT bt DOT com>
Reply-To:	sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host:	dmcap2.aco.aspentech.com
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> I am trying to access a malloced buffer during the mouse interrupt and
> am getting a "page fault cr2=10082000 in RMCB , flags=3006, error = 0006
> the fault occurs in one of my functions called from the interupt as the

If you access memory from a hardware interrupt or a real mode callback
(which is what a mouse interrupt callback is...) you must lock all the
memory you are going to touch.  It's a DPMI requirement, and CWSDPMI
enforces it.  Windows virtualizes enough things to avoid enforcing it
in many cases, but when it doesn't you can sometimes hang the box or
scrogg the hard disk.

Lets suppose you are in the middle of a write statement to the disk when
you move the mouse.  You are in the middle of DOS, which is calling the
BIOS and is stuffing bytes in the IDE I/O port.  Ooops, the memory you
wanted to touch isn't even there, it's virtual memory and is paged out
to disk.  Well, the DPMI server tries to start a write request to save
one of your pages in memory so there will be a free page to bring the
one you want from disk.

But you interrupted DOS and the BIOS in the middle of a write; and you
start stuffing things into the I/O port out of order if you get that far
and dos doesn't die due to it's being non-reentrant.  This can (and has
in early CWSDPMI betas!) destroy your hard disk, including writing over
the partition table and boot block.

Lock the memory.

- Raw text -