Switch context

OSR_Community_User-116 · January 12, 2001, 6:59am

Hi,

stupid question: Is it somehow possible to switch to the system process
context while handling IRP_MJ_CREATE? I guess I could start a thread to
perform the work I need to get done, but I wonder if there might be another
way.

// Johan

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 12, 2001, 9:19am

Johan:

While you can switch to any context by using KeAttachProcess, in the
special case
of the system process you don’t need to. By definition, the system process
only
exists in virtual memory above 0x80000000 and it’s reachable by any kernel
driver
(not by an application). The space above 0x80000000 is mapped into each
process
context but it’s only reachable by priviledged code such as kernel drivers.

George Blat

At 12:55 PM 1/12/01 +0100, you wrote:

Hi,

stupid question: Is it somehow possible to switch to the system process
context while handling IRP_MJ_CREATE? I guess I could start a thread to
perform the work I need to get done, but I wonder if there might be another
way.

// Johan

You are currently subscribed to ntdev as: xxxxx@brd.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

George Blat
BRD Corp
8016 188th SW, Edmonds, WA 98026

phone: 425-775-7475
fax: 781-998-5940
mailto:xxxxx@brd.com
http://www.brd.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User-116 · January 12, 2001, 9:34am

Let me rephrase:

I’m not interested in VM limitations.

What is happening (I think) is that I create a named notification event
inside the IRP_MJ_CREATE dispatch handler the first time it is invoked, and
store the handle reference and PKEVENT inside the driver. After the
application that the create notification originated from has terminated, and
I later reference the event using e.g. KeSetEvent I get the infamous blue
screen.

So my thought was that the handles created in the context of the application
got destroyed/invalidated as part of cleanup when the app terminated (I’ve
verified this as they disappear from the BaseNamedObjects directory as soon
as the app terminates). The app itself never opens/touches the event.

I therefore would like to switch to the system process context so that the
objects created will persist as long as my driver does - but this is all
pretty much wild guesses from my side.

// Johan

-----Original Message-----
From: George Blat [mailto:xxxxx@brd.com]
Sent: den 12 januari 2001 14:18
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

Johan:

While you can switch to any context by using KeAttachProcess, in the
special case
of the system process you don’t need to. By definition, the
system process
only
exists in virtual memory above 0x80000000 and it’s reachable
by any kernel
driver
(not by an application). The space above 0x80000000 is mapped
into each
process
context but it’s only reachable by priviledged code such as
kernel drivers.

George Blat

At 12:55 PM 1/12/01 +0100, you wrote:
>Hi,
>
>stupid question: Is it somehow possible to switch to the
system process
>context while handling IRP_MJ_CREATE? I guess I could start
a thread to
>perform the work I need to get done, but I wonder if there
might be another
>way.
>
>// Johan
>
>—
>You are currently subscribed to ntdev as: xxxxx@brd.com
>To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>

George Blat
BRD Corp
8016 188th SW, Edmonds, WA 98026

phone: 425-775-7475
fax: 781-998-5940
mailto:xxxxx@brd.com
http://www.brd.com

You are currently subscribed to ntdev as: xxxxx@esrange.ssc.se
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 12, 2001, 9:38am

Rather than starting a thread, you can borrow one of the system worker
threads. If you are targeting NT4 look at: ExQueueWorkItem; otherwise for
W2K look at: IoQueueWorkItem.

For some drivers (esp. file system drivers) it might be better to create
your own worker thread pool rather than using the system worker threads. You
probably do not want to actually create a thread on an ‘as needed basis’ and
then terminate it once it performs a single task as the overhead will be
unacceptable.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: xxxxx@esrange.ssc.se
[mailto:xxxxx@esrange.ssc.se]
Sent: Friday, January 12, 2001 6:56 AM
To: NT Developers Interest List
Subject: [ntdev] Switch context

Hi,

stupid question: Is it somehow possible to switch to the
system process
context while handling IRP_MJ_CREATE? I guess I could start a
thread to
perform the work I need to get done, but I wonder if there
might be another
way.

// Johan

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User-116 · January 12, 2001, 9:47am

> -----Original Message-----

From: George Blat [mailto:xxxxx@brd.com]
Sent: den 12 januari 2001 14:18
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

Johan:

While you can switch to any context by using KeAttachProcess, in the

KeAttachProcess?

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 12, 2001, 9:58am

Is undocumented and its use is likely to crash the system.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: xxxxx@esrange.ssc.se
[mailto:xxxxx@esrange.ssc.se]
Sent: Friday, January 12, 2001 9:43 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

> -----Original Message-----
> From: George Blat [mailto:xxxxx@brd.com]
> Sent: den 12 januari 2001 14:18
> To: NT Developers Interest List
> Subject: [ntdev] Re: Switch context
>
>
> Johan:
>
> While you can switch to any context by using KeAttachProcess, in the

KeAttachProcess?

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 12, 2001, 10:06am

>KeAttachProcess?

Another undocumented gem. Let’s not start another thread about the
benefits and evils of considering undocumented functions, because it
has been beaten to death.

The declaration is:

VOID KeAttachProcess(PEPROCESS newprocess);

and newprocess can be obtained by calling IoGetCurrentProcess when
in the right context. For instance driverentry generally runs in the context
of the system process.

After, you must pair that call with KeDetachProcess(void) to go back to
your own
context.

The calls must be done at DISPATCH_LEVEL or below.

George

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 12, 2001, 10:35am

Did you try referencing the PKEVENT in your driver?

-----Original Message-----
From: xxxxx@esrange.ssc.se [mailto:xxxxx@esrange.ssc.se]
Sent: Friday, January 12, 2001 9:31 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

Let me rephrase:

I’m not interested in VM limitations.

What is happening (I think) is that I create a named notification event
inside the IRP_MJ_CREATE dispatch handler the first time it is invoked, and
store the handle reference and PKEVENT inside the driver. After the
application that the create notification originated from has terminated, and
I later reference the event using e.g. KeSetEvent I get the infamous blue
screen.

So my thought was that the handles created in the context of the application
got destroyed/invalidated as part of cleanup when the app terminated (I’ve
verified this as they disappear from the BaseNamedObjects directory as soon
as the app terminates). The app itself never opens/touches the event.

I therefore would like to switch to the system process context so that the
objects created will persist as long as my driver does - but this is all
pretty much wild guesses from my side.

// Johan

-----Original Message-----
From: George Blat [mailto:xxxxx@brd.com]
Sent: den 12 januari 2001 14:18
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

Johan:

While you can switch to any context by using KeAttachProcess, in the
special case
of the system process you don’t need to. By definition, the
system process
only
exists in virtual memory above 0x80000000 and it’s reachable
by any kernel
driver
(not by an application). The space above 0x80000000 is mapped
into each
process
context but it’s only reachable by priviledged code such as
kernel drivers.

George Blat

At 12:55 PM 1/12/01 +0100, you wrote:
>Hi,
>
>stupid question: Is it somehow possible to switch to the
system process
>context while handling IRP_MJ_CREATE? I guess I could start
a thread to
>perform the work I need to get done, but I wonder if there
might be another
>way.
>
>// Johan
>
>—
>You are currently subscribed to ntdev as: xxxxx@brd.com
>To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>

George Blat
BRD Corp
8016 188th SW, Edmonds, WA 98026

phone: 425-775-7475
fax: 781-998-5940
mailto:xxxxx@brd.com
http://www.brd.com

You are currently subscribed to ntdev as: xxxxx@esrange.ssc.se
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 12, 2001, 12:00pm

The PKEVENT object, like any other, is reference counted. You may need to
increase the reference count to avoid destruction.

George Blat

At 03:30 PM 1/12/01 +0100, you wrote:

Let me rephrase:

I’m not interested in VM limitations.

What is happening (I think) is that I create a named notification event
inside the IRP_MJ_CREATE dispatch handler the first time it is invoked, and
store the handle reference and PKEVENT inside the driver. After the
application that the create notification originated from has terminated, and
I later reference the event using e.g. KeSetEvent I get the infamous blue
screen.

So my thought was that the handles created in the context of the application
got destroyed/invalidated as part of cleanup when the app terminated (I’ve
verified this as they disappear from the BaseNamedObjects directory as soon
as the app terminates). The app itself never opens/touches the event.

I therefore would like to switch to the system process context so that the
objects created will persist as long as my driver does - but this is all
pretty much wild guesses from my side.

// Johan

George Blat
BRD Corp
8016 188th SW, Edmonds, WA 98026

phone: 425-775-7475
fax: 781-998-5940
mailto:xxxxx@brd.com
http://www.brd.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 12, 2001, 1:00pm

hi,
everything except HKEY_CURRENT_USER HIVE gets loaded at system start up…
and it has to be that way …as it is user dependent…it gets loaded from
ntuser.dat file for that particular user…
anyways that not the issue right here…
the errors are coming because some of the registry settings are currupted may
be because of improper logging out or shut down…
or there may be another key with same name but in different case.

regards,
hrugved
Rick Winter wrote:

We have seen the error on various paths mostly under
HKEY_LOCAL_MACHINE\Software (in one case looking for the install path for
our code, in another looking under Classes\appId).

I should stress that this is an NT WIN32 service not a driver. It
is my understanding that from a service the local registry should always be
available during startup, at least I have not found anything in the MS
documentation that would indicate otherwise. If you or anyone else knows
differently do you know where I can find documentation detailing what is and
is not available and when? It does appear that it may be some kind of
timing issue because most of the time it works fine, just once in a while we
get this unexplained error.

-----Original Message-----
From: COX,DAVID (HP-Roseville,ex1) [mailto:david_cox2@hp.com]
Sent: Thursday, January 11, 2001 5:38 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Error reading the registry during system startup

What path in the registry? Different hives become available at
different times.

-----------------------------------------------------------------------
Dave Cox
Hewlett-Packard Co.
NSSO/SANS/SMSO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

> -----Original Message-----
> From: Rick Winter [mailto:xxxxx@veritas.com]
> Sent: Thursday, January 11, 2001 10:37 AM
> To: NT Developers Interest List
> Subject: [ntdev] Error reading the registry during system startup
>
>
>
> Has anyone seen a problem reading the local registry during
> service startup
> when the system is booting (Windows 2000)? We are
> sporadically getting
> errors that we cannot explain reading registry entries we
> know exist. If we
> restart the service it starts without any problem and it does
> not happen on
> every boot. The error code does not help much as it is
> either file not
> found or invalid handle.
>
> —
> You are currently subscribed to ntdev as: david_cox2@hp.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: xxxxx@veritas.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@usa.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User-116 · January 13, 2001, 5:15am

Actually I’ll only do this once in the driver’s lifetime, so this looks like
an acceptable solution for me.

Thanks // Johan

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: den 12 januari 2001 15:34
To: NT Developers Interest List
Subject: [ntdev] RE: Switch context

Rather than starting a thread, you can borrow one of the system worker
threads. If you are targeting NT4 look at: ExQueueWorkItem;
otherwise for
W2K look at: IoQueueWorkItem.

For some drivers (esp. file system drivers) it might be
better to create
your own worker thread pool rather than using the system
worker threads. You
probably do not want to actually create a thread on an ‘as
needed basis’ and
then terminate it once it performs a single task as the
overhead will be
unacceptable.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
WindowsNT Windows 2000 Consulting Services

> -----Original Message-----
> From: xxxxx@esrange.ssc.se
> [mailto:xxxxx@esrange.ssc.se]
> Sent: Friday, January 12, 2001 6:56 AM
> To: NT Developers Interest List
> Subject: [ntdev] Switch context
>
>
> Hi,
>
> stupid question: Is it somehow possible to switch to the
> system process
> context while handling IRP_MJ_CREATE? I guess I could start a
> thread to
> perform the work I need to get done, but I wonder if there
> might be another
> way.
>
> // Johan
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

You are currently subscribed to ntdev as: xxxxx@esrange.ssc.se
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User-116 · January 13, 2001, 5:16am

George/Joel,

I’m not sure, but to me it seems like increasing the reference count alone
isn’t enough. The event returned from IoCreateNotificationEvent should
implicitly have the reference count set (or?), and as I never dereference it
or close the handle until driver shuts down it’s got to be something else as
well.

I think using Mark’s tips and call IoCreateNotificationEvent indirectly
using XxQueueWorkItem, should do the trick.

// Johan

-----Original Message-----
From: George Blat [mailto:xxxxx@brd.com]
Sent: den 12 januari 2001 16:59
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

The PKEVENT object, like any other, is reference counted. You
may need to
increase the reference count to avoid destruction.

George Blat

At 03:30 PM 1/12/01 +0100, you wrote:
>Let me rephrase:
>
>I’m not interested in VM limitations.
>
>What is happening (I think) is that I create a named
notification event
>inside the IRP_MJ_CREATE dispatch handler the first time it
is invoked, and
>store the handle reference and PKEVENT inside the driver. After the
>application that the create notification originated from has
terminated, and
>I later reference the event using e.g. KeSetEvent I get the
infamous blue
>screen.
>
>So my thought was that the handles created in the context of
the application
>got destroyed/invalidated as part of cleanup when the app
terminated (I’ve
>verified this as they disappear from the BaseNamedObjects
directory as soon
>as the app terminates). The app itself never opens/touches the event.
>
>I therefore would like to switch to the system process
context so that the
>objects created will persist as long as my driver does - but
this is all
>pretty much wild guesses from my side.
>
>// Johan
>

George Blat
BRD Corp
8016 188th SW, Edmonds, WA 98026

phone: 425-775-7475
fax: 781-998-5940
mailto:xxxxx@brd.com
http://www.brd.com

You are currently subscribed to ntdev as: xxxxx@esrange.ssc.se
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 13, 2001, 2:17pm

Johan:

NT objects have two reference counter fields. One is for handles, the other
is for
pointers. Both hold the number of each that point or refer to the object.

When you close the process, the handle counter reaches zero, and if at that
time the
pointer refcounter is also zero the object will be released/destroyed. If
you want
to have that object available to your driver in any context and even after
the process
that started it may be gone, you obtain a pointer to that object from the
handle. By
obtaining that pointer the pointer reference count is incremented and the
object will stay in memory. If you did not do it already, you may look into
ObReferenceObjectByHandle.

George Blat

At 11:12 AM 1/13/01 +0100, you wrote:

George/Joel,

I’m not sure, but to me it seems like increasing the reference count alone
isn’t enough. The event returned from IoCreateNotificationEvent should
implicitly have the reference count set (or?), and as I never dereference it
or close the handle until driver shuts down it’s got to be something else as
well.

I think using Mark’s tips and call IoCreateNotificationEvent indirectly
using XxQueueWorkItem, should do the trick.

// Johan

> -----Original Message-----
> From: George Blat [mailto:xxxxx@brd.com]
> Sent: den 12 januari 2001 16:59
> To: NT Developers Interest List
> Subject: [ntdev] Re: Switch context
>
>
> The PKEVENT object, like any other, is reference counted. You
> may need to
> increase the reference count to avoid destruction.
>
> George Blat
>
> At 03:30 PM 1/12/01 +0100, you wrote:
> >Let me rephrase:
> >
> >I’m not interested in VM limitations.
> >
> >What is happening (I think) is that I create a named
> notification event
> >inside the IRP_MJ_CREATE dispatch handler the first time it
> is invoked, and
> >store the handle reference and PKEVENT inside the driver. After the
> >application that the create notification originated from has
> terminated, and
> >I later reference the event using e.g. KeSetEvent I get the
> infamous blue
> >screen.
> >
> >So my thought was that the handles created in the context of
> the application
> >got destroyed/invalidated as part of cleanup when the app
> terminated (I’ve
> >verified this as they disappear from the BaseNamedObjects
> directory as soon
> >as the app terminates). The app itself never opens/touches the event.
> >
> >I therefore would like to switch to the system process
> context so that the
> >objects created will persist as long as my driver does - but
> this is all
> >pretty much wild guesses from my side.
> >
> >// Johan
> >
>
> -------------------------------------------
> George Blat
> BRD Corp
> 8016 188th SW, Edmonds, WA 98026
>
> phone: 425-775-7475
> fax: 781-998-5940
> mailto:xxxxx@brd.com
> http://www.brd.com
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@esrange.ssc.se
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

You are currently subscribed to ntdev as: xxxxx@brd.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

George Blat
BRD Corp
8016 188th SW, Edmonds, WA 98026

phone: 425-775-7475
fax: 781-998-5940
mailto:xxxxx@brd.com
http://www.brd.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User-116 · January 15, 2001, 3:19am

I just checked into ‘Inside Windows 2000’, and there it looks like the
objects got an open handle count and a total reference count (including the
handle count).

Sorry if I keep insisting on this, but do you mean that the PKEVENT returned
by IoCreateNotificationEvent does only have it’s reference count set to one
(for the handle), so when that handle is implicitly closed when the app
exits, the event will be destroyed?

It would somehow make more sense that the KEVENT object would have it’s
total reference count set to 2, one for the returned handle, and one for the
returned pointer. Anyway, I’ll try it out.

Thanks // Johan

-----Original Message-----
From: George Blat [mailto:xxxxx@brd.com]
Sent: den 13 januari 2001 19:16
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

Johan:

NT objects have two reference counter fields. One is for
handles, the other
is for
pointers. Both hold the number of each that point or refer to
the object.

When you close the process, the handle counter reaches zero,
and if at that
time the
pointer refcounter is also zero the object will be
released/destroyed. If
you want
to have that object available to your driver in any context
and even after
the process
that started it may be gone, you obtain a pointer to that
object from the
handle. By
obtaining that pointer the pointer reference count is
incremented and the
object will stay in memory. If you did not do it already, you
may look into
ObReferenceObjectByHandle.

George Blat

At 11:12 AM 1/13/01 +0100, you wrote:
>George/Joel,
>
>I’m not sure, but to me it seems like increasing the
reference count alone
>isn’t enough. The event returned from
IoCreateNotificationEvent should
>implicitly have the reference count set (or?), and as I
never dereference it
>or close the handle until driver shuts down it’s got to be
something else as
>well.
>
>I think using Mark’s tips and call IoCreateNotificationEvent
indirectly
>using XxQueueWorkItem, should do the trick.
>
>// Johan
>
>> -----Original Message-----
>> From: George Blat [mailto:xxxxx@brd.com]
>> Sent: den 12 januari 2001 16:59
>> To: NT Developers Interest List
>> Subject: [ntdev] Re: Switch context
>>
>>
>> The PKEVENT object, like any other, is reference counted. You
>> may need to
>> increase the reference count to avoid destruction.
>>
>> George Blat
>>
>> At 03:30 PM 1/12/01 +0100, you wrote:
>> >Let me rephrase:
>> >
>> >I’m not interested in VM limitations.
>> >
>> >What is happening (I think) is that I create a named
>> notification event
>> >inside the IRP_MJ_CREATE dispatch handler the first time it
>> is invoked, and
>> >store the handle reference and PKEVENT inside the driver.
After the
>> >application that the create notification originated from has
>> terminated, and
>> >I later reference the event using e.g. KeSetEvent I get the
>> infamous blue
>> >screen.
>> >
>> >So my thought was that the handles created in the context of
>> the application
>> >got destroyed/invalidated as part of cleanup when the app
>> terminated (I’ve
>> >verified this as they disappear from the BaseNamedObjects
>> directory as soon
>> >as the app terminates). The app itself never
opens/touches the event.
>> >
>> >I therefore would like to switch to the system process
>> context so that the
>> >objects created will persist as long as my driver does - but
>> this is all
>> >pretty much wild guesses from my side.
>> >
>> >// Johan
>> >
>>
>> -------------------------------------------
>> George Blat
>> BRD Corp
>> 8016 188th SW, Edmonds, WA 98026
>>
>> phone: 425-775-7475
>> fax: 781-998-5940
>> mailto:xxxxx@brd.com
>> http://www.brd.com
>>
>>
>>
>>
>> —
>> You are currently subscribed to ntdev as:
xxxxx@esrange.ssc.se
>> To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>>
>
>—
>You are currently subscribed to ntdev as: xxxxx@brd.com
>To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>

George Blat
BRD Corp
8016 188th SW, Edmonds, WA 98026

phone: 425-775-7475
fax: 781-998-5940
mailto:xxxxx@brd.com
http://www.brd.com

You are currently subscribed to ntdev as: xxxxx@esrange.ssc.se
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 15, 2001, 6:11am

Yes, it is exactly like you’re saying.

TotalReferenceCount = ReferenceCount + HandleCount
i.e. there is one additional reference for any handle.

And KEVENT returned from IoCreateXxxxxEvent has
ReferenceCount really equal to one.
It is also evident from steps done in the routine:

ZwCreateEvent //RefCnt = 1, HndCnt = 1
ObReferenceObjectByhandle //RefCnt = 2, HndCnt = 1
ObDereferenceObject //RefCnt = 1, HndCnt = 1

Referencing (and dereferencing) is done only for obtaining
event pointer.

So if you can ensure the event remains valid you must do
one additional referencing right after IoCreateXxxxEvent.

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@esrange.ssc.se
Sent: Monday, January 15, 2001 9:15 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

I just checked into ‘Inside Windows 2000’, and there it looks like the
objects got an open handle count and a total reference count (including
the
handle count).

Sorry if I keep insisting on this, but do you mean that the PKEVENT
returned
by IoCreateNotificationEvent does only have it’s reference count set to
one
(for the handle), so when that handle is implicitly closed when the app
exits, the event will be destroyed?

It would somehow make more sense that the KEVENT object would have it’s
total reference count set to 2, one for the returned handle, and one for
the
returned pointer. Anyway, I’ll try it out.

Thanks // Johan

-----Original Message-----
From: George Blat [mailto:xxxxx@brd.com]
Sent: den 13 januari 2001 19:16
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

Johan:

NT objects have two reference counter fields. One is for
handles, the other
is for
pointers. Both hold the number of each that point or refer to
the object.

When you close the process, the handle counter reaches zero,
and if at that
time the
pointer refcounter is also zero the object will be
released/destroyed. If
you want
to have that object available to your driver in any context
and even after
the process
that started it may be gone, you obtain a pointer to that
object from the
handle. By
obtaining that pointer the pointer reference count is
incremented and the
object will stay in memory. If you did not do it already, you
may look into
ObReferenceObjectByHandle.

George Blat

At 11:12 AM 1/13/01 +0100, you wrote:
>George/Joel,
>
>I’m not sure, but to me it seems like increasing the
reference count alone
>isn’t enough. The event returned from
IoCreateNotificationEvent should
>implicitly have the reference count set (or?), and as I
never dereference it
>or close the handle until driver shuts down it’s got to be
something else as
>well.
>
>I think using Mark’s tips and call IoCreateNotificationEvent
indirectly
>using XxQueueWorkItem, should do the trick.
>
>// Johan
>
>> -----Original Message-----
>> From: George Blat [mailto:xxxxx@brd.com]
>> Sent: den 12 januari 2001 16:59
>> To: NT Developers Interest List
>> Subject: [ntdev] Re: Switch context
>>
>>
>> The PKEVENT object, like any other, is reference counted. You
>> may need to
>> increase the reference count to avoid destruction.
>>
>> George Blat
>>
>> At 03:30 PM 1/12/01 +0100, you wrote:
>> >Let me rephrase:
>> >
>> >I’m not interested in VM limitations.
>> >
>> >What is happening (I think) is that I create a named
>> notification event
>> >inside the IRP_MJ_CREATE dispatch handler the first time it
>> is invoked, and
>> >store the handle reference and PKEVENT inside the driver.
After the
>> >application that the create notification originated from has
>> terminated, and
>> >I later reference the event using e.g. KeSetEvent I get the
>> infamous blue
>> >screen.
>> >
>> >So my thought was that the handles created in the context of
>> the application
>> >got destroyed/invalidated as part of cleanup when the app
>> terminated (I’ve
>> >verified this as they disappear from the BaseNamedObjects
>> directory as soon
>> >as the app terminates). The app itself never
opens/touches the event.
>> >
>> >I therefore would like to switch to the system process
>> context so that the
>> >objects created will persist as long as my driver does - but
>> this is all
>> >pretty much wild guesses from my side.
>> >
>> >// Johan
>> >
>>
>>

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

>> George Blat
>> BRD Corp
>> 8016 188th SW, Edmonds, WA 98026
>>
>> phone: 425-775-7475
>> fax: 781-998-5940
>> mailto:xxxxx@brd.com
>> http://www.brd.com
>>
>>
>>
>>
>> —
>> You are currently subscribed to ntdev as:
xxxxx@esrange.ssc.se
>> To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>>
>
>—
>You are currently subscribed to ntdev as: xxxxx@brd.com
>To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>

George Blat
BRD Corp
8016 188th SW, Edmonds, WA 98026

phone: 425-775-7475
fax: 781-998-5940
mailto:xxxxx@brd.com
http://www.brd.com

You are currently subscribed to ntdev as: xxxxx@esrange.ssc.se
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@compelson.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User-116 · January 15, 2001, 6:51am

Thanks,

now I think that I can at least understand what went on.

Unfortunately, even incrementing the reference count in this context doesn’t
help, as the object’s name is still deleted from BaseNamedObjects directory
when all handle references to it are closed. I ended up using
XxQueueWorkItem and call IoCreateNotificationEvent from inside the procedure
to fix the problem - which seems to work.

This last part I’m not sure about: It seemed like the KEVENT itself was also
destroyed after the app exited even though I additionally referenced it
right after creation. I created the event using IoCreateNotificationEvent()
and right afterwards called ObReferenceObject() and got a page fault in my
driver when accessing the event some time after the application exited -
even with the extra reference count. The event was in this case created and
referenced inside my IRP_MJ_CREATE handler. Is this possible or am I
mistaken?

// Johan

-----Original Message-----
From: Hrdina Pavel [mailto:xxxxx@compelson.com]
Sent: den 15 januari 2001 12:01
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

Yes, it is exactly like you’re saying.
TotalReferenceCount = ReferenceCount + HandleCount
i.e. there is one additional reference for any handle.
And KEVENT returned from IoCreateXxxxxEvent has
ReferenceCount really equal to one.
It is also evident from steps done in the routine:
ZwCreateEvent //RefCnt = 1, HndCnt = 1
ObReferenceObjectByhandle //RefCnt = 2, HndCnt = 1
ObDereferenceObject //RefCnt = 1, HndCnt = 1
Referencing (and dereferencing) is done only for obtaining
event pointer.
So if you can ensure the event remains valid you must do
one additional referencing right after IoCreateXxxxEvent.
Paul

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · January 15, 2001, 7:33am

Why you are not using ZwDuplicateObject ?

You must have handle to initial system process - you can obtain it
by opening the process in which context your DriverEntry was called.
In DriverEntry save PsGetCurrentProcess() to some variable.
Then when you have called IoCreateXxxxEvent, call:

ObOpenObjectByPointer(
SavedSystemProcessPointer,
0,
NULL,
PROCESS_DUP_HANDLE,
*PsProcessType,
KernelMode,
&SystemProcessHandle );

ZwDuplicateObject(
NtCurrentProcess(),
EventHandle,
SystemProcessHandle,
&TargetHandle,
0,
0,
SUPLICATE_SAME_ACCESS | DUPLICATE_SAME_ATTRIBUTES );

ZwClose(SystemProcessHandle);

Also if you want to close EventHandle you have to |
DUPLICATE_CLOSE_SOURCE
or call ZwClose after duplication.

Another way to force IoCreateXxxxEvent to create the handle in some
other
process context is to attach to this process before calling it.

KeAttachProcess((PKPROCESS)SavedSystemProcessPointer);
IoCreateXxxxxEvent(…);
KeDetachProcess();

After this returned handle should reside in the system process context.
But this technique should be tested, I’m not sure if it is clear.

Hope this helps.
Paul

//
// Needed prototypes (mostly from NTIFS.H)
//

NTKERNELAPI
VOID
KeAttachProcess (
IN PRKPROCESS Process
);

NTKERNELAPI
VOID
KeDetachProcess (
VOID
);

#define DUPLICATE_CLOSE_SOURCE 0x00000001
#define DUPLICATE_SAME_ACCESS 0x00000002
#define DUPLICATE_SAME_ATTRIBUTES 0x00000004

NTSYSAPI
NTSTATUS
NTAPI
ZwDuplicateObject (
IN HANDLE SourceProcessHandle,
IN HANDLE SourceHandle,
IN HANDLE TargetProcessHandle OPTIONAL,
OUT PHANDLE TargetHandle OPTIONAL,
IN ACCESS_MASK DesiredAccess,
IN ULONG HandleAttributes,
IN ULONG Options
);

NTKERNELAPI
NTSTATUS
ObOpenObjectByPointer (
IN PVOID Object,
IN ULONG HandleAttributes,
IN PACCESS_STATE PassedAccessState OPTIONAL,
IN ACCESS_MASK DesiredAccess OPTIONAL,
IN POBJECT_TYPE ObjectType OPTIONAL,
IN KPROCESSOR_MODE AccessMode,
OUT PHANDLE Handle
);

#define PROCESS_DUP_HANDLE (0x0040)

extern POBJECT_TYPE *PsProcessType;

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@esrange.ssc.se
Sent: Monday, January 15, 2001 12:48 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

Thanks,

now I think that I can at least understand what went on.

Unfortunately, even incrementing the reference count in this context
doesn’t
help, as the object’s name is still deleted from BaseNamedObjects
directory
when all handle references to it are closed. I ended up using
XxQueueWorkItem and call IoCreateNotificationEvent from inside the
procedure
to fix the problem - which seems to work.

This last part I’m not sure about: It seemed like the KEVENT itself was
also
destroyed after the app exited even though I additionally referenced it
right after creation. I created the event using
IoCreateNotificationEvent()
and right afterwards called ObReferenceObject() and got a page fault in
my
driver when accessing the event some time after the application exited -
even with the extra reference count. The event was in this case created
and
referenced inside my IRP_MJ_CREATE handler. Is this possible or am I
mistaken?

// Johan

-----Original Message-----
From: Hrdina Pavel [mailto:xxxxx@compelson.com]
Sent: den 15 januari 2001 12:01
To: NT Developers Interest List
Subject: [ntdev] Re: Switch context

Yes, it is exactly like you’re saying.
TotalReferenceCount = ReferenceCount + HandleCount
i.e. there is one additional reference for any handle.
And KEVENT returned from IoCreateXxxxxEvent has
ReferenceCount really equal to one.
It is also evident from steps done in the routine:
ZwCreateEvent //RefCnt = 1, HndCnt = 1
ObReferenceObjectByhandle //RefCnt = 2, HndCnt = 1
ObDereferenceObject //RefCnt = 1, HndCnt = 1
Referencing (and dereferencing) is done only for obtaining
event pointer.
So if you can ensure the event remains valid you must do
one additional referencing right after IoCreateXxxxEvent.
Paul

You are currently subscribed to ntdev as: xxxxx@compelson.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com