Re: Assert being the highest-level driver

It's the mode of the processor before the last system call.

So user-mode app calls NtOpenFile, previous mode is UserMode.
Kernel thread (or user-thread running in kernel-mode) calls NtOpenFile, previous mode becomes KernelMode.

-p

-----Original Message-----
From: ijor@nospam.nospam
Posted At: Thursday, August 11, 2005 8:20 AM
Posted To: microsoft.public.development.device.drivers
Conversation: Assert being the highest-level driver
Subject: Re: Assert being the highest-level driver



"Doron Holan [MS]" wrote:

> you can't reliably do this. you have to take it on faith that if the
> design of your stack is that you are the highest level driver, you are the highest.

I see, thanks.

But just for my knowledge, what is exactly the meaning of "previous" in ExGetPreviousMode? The concept is a bit loose in this context.

ijor
Thu Aug 11 16:21:04 CDT 2005

Hmm, I probably miss something. Because otherwise I don't understand how this
could be useful as claimed by the docs.

How can I know if by the time I call ExGetPreviousMode some other thread
made a system call and changed the "previous mode"?

> "Peter Wieland [MSFT]" wrote:
>
> It's the mode of the processor before the last system call.
>
> -----Original Message-----
> From: ijor@nospam.nospam
> Posted At: Thursday, August 11, 2005 8:20 AM
> Posted To: microsoft.public.development.device.drivers
> Conversation: Assert being the highest-level driver
> Subject: Re: Assert being the highest-level driver
>
>
>
> "Doron Holan [MS]" wrote:
>
> > you can't reliably do this. you have to take it on faith that if the
> > design of your stack is that you are the highest level driver, you are the highest.
>
> I see, thanks.
>
> But just for my knowledge, what is exactly the meaning of "previous" in ExGetPreviousMode? The concept is a bit loose in this context.

pavel_a
Thu Aug 11 19:04:04 CDT 2005

"ijor" wrote:
> Hmm, I probably miss something. Because otherwise I don't understand how this
> could be useful as claimed by the docs.

Well, not every function mentioned in the docs is useful.
And some useful stuff is not documented (as you have seen recently ;)
Drivers just use irp.RequestorMode. A system service that translates
call parameters to the IRP, sets this field for you.

Regards,
--PA

> How can I know if by the time I call ExGetPreviousMode some other thread
> made a system call and changed the "previous mode"?
>
> > "Peter Wieland [MSFT]" wrote:
> >
> > It's the mode of the processor before the last system call.
> >
> > -----Original Message-----
> > From: ijor@nospam.nospam
> > Posted At: Thursday, August 11, 2005 8:20 AM
> > Posted To: microsoft.public.development.device.drivers
> > Conversation: Assert being the highest-level driver
> > Subject: Re: Assert being the highest-level driver
> >
> >
> >
> > "Doron Holan [MS]" wrote:
> >
> > > you can't reliably do this. you have to take it on faith that if the
> > > design of your stack is that you are the highest level driver, you are the highest.
> >
> > I see, thanks.
> >
> > But just for my knowledge, what is exactly the meaning of "previous" in ExGetPreviousMode? The concept is a bit loose in this context.
>

Maxim
Thu Aug 11 20:14:52 CDT 2005

> Kernel thread (or user-thread running in kernel-mode) calls NtOpenFile,
>previous mode becomes KernelMode.

From what I know, kernel thread must call ZwOpenFile to do this :)

NtOpenFile is a syscall body, it must not be called except from the
KiSystemService dispatcher, otherwise, it will run with bad previous mode.

ZwOpenFile is a trap though, which creates a trap frame on the stack, executes
the trap prolog (this sets the correct previous mode), KiSystemService and then
arriving to NtOpenFile.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com