> -----Original Message-----
> From: Casper Hornstrup [mailto:ch@csh-consult.dk]
> Sent: 03 March 2005 12:36
> To: 'ReactOS Development List'
> Subject: RE: [ros-dev] Alex has fixed the laptop problem
>
>
> > -----Original Message-----
> > From: ros-dev-bounces(a)reactos.com
> > [mailto:ros-dev-bounces@reactos.com] On Behalf Of Murphy, Ged (Bolton)
> > Sent: 3. marts 2005 09:25
> > To: 'ReactOS Development List'
> > Subject: RE: [ros-dev] Alex has fixed the laptop problem
> >
> > Alex Ionescu wrote:
> >
> > > Do you want to delay 0.2.6 until I merge with tip? Else it
> > will be for
> > > 0.3.x/0.2.7
> > >
> > > Best regards,
> > > Alex Ionescu
> >
> > What is tip ?
>
> He means trunk. Tip (or HEAD) is the latest revision in the repository.
>
Alex, when will you be ready to merge ?
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Alex Ionescu wrote:
> Do you want to delay 0.2.6 until I merge with tip? Else it will be for
> 0.3.x/0.2.7
>
> Best regards,
> Alex Ionescu
What is tip ?
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
FWIW, Alex is also experiencing this problem...
Basically while shutting down for reboot, I hit Ctrl+Alt on the
keyboard, and it crashed.
Here's the dump:
(smss.c:85) SM: Process terminated!
(ke/error.c:54) Hard error c000021a
(ke/catch.c:142) Unhandled UserMode exception, terminating thread
KeBugCheckWithTf at ke/catch.c:177
Bug detected (code 1e param 0 0 0 0)
KMODE_EXCEPTION_NOT_HANDLED
Page Fault Exception: 14(0)
Processor: 0 CS:EIP 8:9d5b40ef <win32k.sys: 180ef>
cr2 cdcdcef1 cr3 27000 Proc: 8048d8e0 Pid: 4 <System> Thrd: 80670050 Tid: 78
DS 10 ES 10 FS 30 GS 10
EAX: cdcdcdcd EBX: 9d5b3db2 ECX: 80593a50
EDX: 80670084 EBP: 9d70fdd8 ESI: 00000000 ESP: 9d70fcbc
EDI: 00000000 EFLAGS: 00000282 kESP 9d70fcbc kernel stack base 9d70d000
Frames:
<ntoskrnl.exe: 33f0>
here's the assembly instruction where we crashed:
<win32k.sys: 180ef> cmpl $0x0,0x124(%eax)
here's what addr2line gives:
C:\cvs\reactos\subsys\win32k>a 180ef
C:/cvs/reactos/subsys/win32k/ntuser/input.c:380
subsys/win32k/ntuser/input.c:380:
if (FocusThread && FocusThread->Tcb.Win32Thread &&
so FocusThread is 0xcdcdcdcd, which means that the FocusQueue holding it is getting deleted out from under us.
after initial examination, we aren't ref counting the desktop or the queue when we obtain it via IntGetFocusMessageQueue().
as this bug is occuring on shutdown, I think the most proper solution is to reference the msgqueue until we're done with it there in ntuser/input.c.
However, in order to safely reference the msgqueue, it seems we really need to reference the desktop at least long enough to obtain the msgqueue pointer and reference it.
This sounds very slow, so I'm wondering if there's a better fix than that...
I was thinking we could add a "shutdown hack" for this, by at the very least killing InputDesktop sooner, but it seems that might not help in situations where we're killing one of many desktops.
Anyways, I'm not confident what should be done in this case, so I'm passing this information to the list in hopes that someone more familiar with the msgqueue code can fix it.
Thanks,
Royce Mitchell III
<ntoskrnl.exe: 33f0>