IoBuildSynchronousFsdRequest delays boot time.

OSR_Community_User · February 13, 2009, 8:14pm

Hello,

I have a question about the IoBuildSynchronousFsdRequest() method.
I am developing a storage filter driver, from my IRP_MJ_WRITE dispatch routine I have to update a file by building an IRP with IoBuildSynchronousFsdRequest() call. I do that only when IRQL value is PASSIVE_LEVEL, otherwise I put IRP’s data (size, offset) to my private queue and process them later. Everything works fine on regular, non-system volumes. If I install the driver on a system volume, the boot is delayed for 5-8 minutes. The code of the method is:

NTSTATUS ForwardIrpDirectly(PDEVICE_OBJECT xi_device_object,
ULONG xi_mj_function,
BYTE* xio_buffer,
ULONG xi_buffer_size,
LARGE_INTEGER* xi_offset,
IO_STATUS_BLOCK* xo_iosb)
{
NTSTATUS result = STATUS_SUCCESS;

TraceRoutine(DEBUG_LEVEL_TRACE, (“ForwardIrpDirectly: init, IRQL [%ld].”, KeGetCurrentIrql()));

ASSERT_IRQL(PASSIVE_LEVEL);

NT_ASSERT(xi_device_object != NULL && xo_iosb != NULL);

if(xi_device_object != NULL && xo_iosb != NULL)
{
IRP* irp;

KEVENT event;

if(xi_mj_function == IRP_MJ_READ || xi_mj_function == IRP_MJ_WRITE)
{
NT_ASSERT(xio_buffer != NULL && xi_buffer_size > 0 && xi_offset != NULL);
}

KeInitializeEvent(&event, NotificationEvent, FALSE);

irp = IoBuildSynchronousFsdRequest(xi_mj_function,
xi_device_object,
xio_buffer,
xi_buffer_size,
xi_offset,
&event,
xo_iosb);

if(irp == NULL)
{
result = STATUS_INSUFFICIENT_RESOURCES;
}

if(NT_SUCCESS(result))
{
(*irp).Flags |= IRP_NOCACHE;

result = IoCallDriver(xi_device_object, irp);

if(result == STATUS_PENDING)
{
KeEnterCriticalRegion();
KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);
KeLeaveCriticalRegion();

result = (*xo_iosb).Status;
}
}
else
{
// log error
TraceRoutine(DEBUG_LEVEL_LOGGING, (“ERROR: [%X], %s (%ld)”, result, FILE, LINE));
}
}
else
{
// log error
result = STATUS_INVALID_PARAMETER;
TraceRoutine(DEBUG_LEVEL_LOGGING, (“ERROR: [%X], %s (%ld)”, result, FILE, LINE));
}

TraceRoutine(DEBUG_LEVEL_TRACE, (“ForwardIrpDirectly: final [%X].”, result));

return result;
}

At some point, I commented out everything except that call to IoBuildSynchronousFsdRequest() and the system still delayed to boot. Is anything special about this method? How a system drive (C:) is different from a regular one from that method point of view? I tried with and without the page file (just a thought).

Thank you in advance,

Arthur

David_J_Craig · February 13, 2009, 9:02pm

You might want to consider creating a bunch of requests and putting them in
a queue to eliminate the delay. Requests on a paging volume where the page
file is located or lots of executables are located that are loaded via
paging reads may come in at higher IRQLs than should be used with that
request. There will also be a lot of those type of reads and depending upon
what runs at startup, it may take a considerable time. Windows is way too
slow as is and this will only increase the slowness significantly. Consider
doing all reads and writes to the system/boot volume (where the WINDOWS
directory resides) the same way as when IRQL is > PASSIVE_LEVEL. The
critical region calls around the wait appear suspicious??? Lots of the
various operating system executables will be paged out and will require a
read to bring them back into memory. Also don’t forget the DLLs found in
the WINDOWS directory and its subdirectories such as C RunTimes that will
also be heavily paged. You might be able to see improved performance on a
64-bit version of Windows with at least 8GB of memory, though it might
require 16GB to keep any of those pages from getting released during boot.
Try it and see how much difference it makes.

wrote in message news:xxxxx@ntdev…
> Hello,
>
> I have a question about the IoBuildSynchronousFsdRequest() method.
> I am developing a storage filter driver, from my IRP_MJ_WRITE dispatch
> routine I have to update a file by building an IRP with
> IoBuildSynchronousFsdRequest() call. I do that only when IRQL value is
> PASSIVE_LEVEL, otherwise I put IRP’s data (size, offset) to my private
> queue and process them later. Everything works fine on regular, non-system
> volumes. If I install the driver on a system volume, the boot is delayed
> for 5-8 minutes. The code of the method is:
>
> NTSTATUS ForwardIrpDirectly(PDEVICE_OBJECT xi_device_object,
> ULONG xi_mj_function,
> BYTE* xio_buffer,
> ULONG xi_buffer_size,
> LARGE_INTEGER* xi_offset,
> IO_STATUS_BLOCK* xo_iosb)
> {
> NTSTATUS result = STATUS_SUCCESS;
>
> TraceRoutine(DEBUG_LEVEL_TRACE, (“ForwardIrpDirectly: init, IRQL
> [%ld].”, KeGetCurrentIrql()));
>
> ASSERT_IRQL(PASSIVE_LEVEL);
>
> NT_ASSERT(xi_device_object != NULL && xo_iosb != NULL);
>
> if(xi_device_object != NULL && xo_iosb != NULL)
> {
> IRP* irp;
>
> KEVENT event;
>
> if(xi_mj_function == IRP_MJ_READ || xi_mj_function == IRP_MJ_WRITE)
> {
> NT_ASSERT(xio_buffer != NULL && xi_buffer_size > 0 && xi_offset
> != NULL);
> }
>
> KeInitializeEvent(&event, NotificationEvent, FALSE);
>
> irp = IoBuildSynchronousFsdRequest(xi_mj_function,
> xi_device_object,
> xio_buffer,
> xi_buffer_size,
> xi_offset,
> &event,
> xo_iosb);
>
> if(irp == NULL)
> {
> result = STATUS_INSUFFICIENT_RESOURCES;
> }
>
> if(NT_SUCCESS(result))
> {
> (*irp).Flags |= IRP_NOCACHE;
>
> result = IoCallDriver(xi_device_object, irp);
>
> if(result == STATUS_PENDING)
> {
> KeEnterCriticalRegion();
> KeWaitForSingleObject(&event, Executive, KernelMode, FALSE,
> NULL);
> KeLeaveCriticalRegion();
>
> result = (*xo_iosb).Status;
> }
> }
> else
> {
> // log error
> TraceRoutine(DEBUG_LEVEL_LOGGING, (“ERROR: [%X], %s (%ld)”,
> result, FILE , LINE ));
> }
> }
> else
> {
> // log error
> result = STATUS_INVALID_PARAMETER;
> TraceRoutine(DEBUG_LEVEL_LOGGING, (“ERROR: [%X], %s (%ld)”, result,
> FILE , LINE ));
> }
>
> TraceRoutine(DEBUG_LEVEL_TRACE, (“ForwardIrpDirectly: final [%X].”,
> result));
>
> return result;
> }
>
> At some point, I commented out everything except that call to
> IoBuildSynchronousFsdRequest() and the system still delayed to boot. Is
> anything special about this method? How a system drive (C:) is different
> from a regular one from that method point of view? I tried with and
> without the page file (just a thought).
>
> Thank you in advance,
>
> Arthur
>

OSR_Community_User · February 13, 2009, 9:19pm

> The code of the method is
I would bet that IoBuildSynchronousFsdRequest is not the culprit.
It just, well, builds the irp, not a big deal.

From WDK docs on KeWaitForSingleObject:

“If a NULL pointer is supplied for Timeout, the calling thread
remains in a wait state until the Object is signaled.”

Can it be that this way you block a thread that is vital
during boot?

Btw, when I had similar problem, I just cached all I have to save
in a dequeue-like structure until the boot is over, and spat it out
later, when it’s safe.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, February 13, 2009 8:14 PM
Subject: [ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Hello,
>
> I have a question about the IoBuildSynchronousFsdRequest() method.
> I am developing a storage filter driver, from my IRP_MJ_WRITE dispatch
> routine I have to update a file by building an IRP with
> IoBuildSynchronousFsdRequest() call. I do that only when IRQL value is
> PASSIVE_LEVEL, otherwise I put IRP’s data (size, offset) to my private
> queue and process them later. Everything works fine on regular, non-system
> volumes. If I install the driver on a system volume, the boot is delayed
> for 5-8 minutes. The code of the method is:
>
> NTSTATUS ForwardIrpDirectly(PDEVICE_OBJECT xi_device_object,
> ULONG xi_mj_function,
> BYTE* xio_buffer,
> ULONG xi_buffer_size,
> LARGE_INTEGER* xi_offset,
> IO_STATUS_BLOCK* xo_iosb)
> {
> NTSTATUS result = STATUS_SUCCESS;
>
> TraceRoutine(DEBUG_LEVEL_TRACE, (“ForwardIrpDirectly: init, IRQL
> [%ld].”, KeGetCurrentIrql()));
>
> ASSERT_IRQL(PASSIVE_LEVEL);
>
> NT_ASSERT(xi_device_object != NULL && xo_iosb != NULL);
>
> if(xi_device_object != NULL && xo_iosb != NULL)
> {
> IRP* irp;
>
> KEVENT event;
>
> if(xi_mj_function == IRP_MJ_READ || xi_mj_function == IRP_MJ_WRITE)
> {
> NT_ASSERT(xio_buffer != NULL && xi_buffer_size > 0 && xi_offset
> != NULL);
> }
>
> KeInitializeEvent(&event, NotificationEvent, FALSE);
>
> irp = IoBuildSynchronousFsdRequest(xi_mj_function,
> xi_device_object,
> xio_buffer,
> xi_buffer_size,
> xi_offset,
> &event,
> xo_iosb);
>
> if(irp == NULL)
> {
> result = STATUS_INSUFFICIENT_RESOURCES;
> }
>
> if(NT_SUCCESS(result))
> {
> (*irp).Flags |= IRP_NOCACHE;
>
> result = IoCallDriver(xi_device_object, irp);
>
> if(result == STATUS_PENDING)
> {
> KeEnterCriticalRegion();
> KeWaitForSingleObject(&event, Executive, KernelMode, FALSE,
> NULL);
> KeLeaveCriticalRegion();
>
> result = (*xo_iosb).Status;
> }
> }
> else
> {
> // log error
> TraceRoutine(DEBUG_LEVEL_LOGGING, (“ERROR: [%X], %s (%ld)”,
> result, FILE , LINE ));
> }
> }
> else
> {
> // log error
> result = STATUS_INVALID_PARAMETER;
> TraceRoutine(DEBUG_LEVEL_LOGGING, (“ERROR: [%X], %s (%ld)”, result,
> FILE , LINE ));
> }
>
> TraceRoutine(DEBUG_LEVEL_TRACE, (“ForwardIrpDirectly: final [%X].”,
> result));
>
> return result;
> }
>
> At some point, I commented out everything except that call to
> IoBuildSynchronousFsdRequest() and the system still delayed to boot. Is
> anything special about this method? How a system drive (C:) is different
> from a regular one from that method point of view? I tried with and
> without the page file (just a thought).
>
> Thank you in advance,
>
> Arthur
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · February 13, 2009, 11:29pm

Thank you for replies.

…until the boot is over
Is there a way to determine when is the system fully loaded?

Thanks again.

Arthur

OSR_Community_User · February 14, 2009, 8:37am

> Is there a way to determine when is the system fully loaded?
My guess would be that there is no such thing (what is “fully”?)

Cheap and dirty [but I am not saying that this cannot be used
in production]: try saving 100 irps, if the boot is still long,
try 1000, if boot is fast, try 500 etc.

In my case a queue of 600 was long enough, but I may be wrong.

Two more things, however:

You disable the delivery of normal kernel APCs [special
kernel-mode APCs are still delivered] by wrapping
KeWaitForSingleObject by a KeEnter/LeaveCriticalRegion pair.

Why? What for?

From http://www.osronline.com/DDKx/kmarch/k105_40c2.htm:
“A thread is never alerted, nor is its wait aborted, by the delivery
of a kernel-mode APC.”

And since you have the 4th parameter of a wait (Alertable) set
to FALSE, user-mode APCs do not break the wait either.

So - what are you trying to achieve here?

Alertable = FALSE was good enough for me without these
wrappers.

Here is my guess on what really goes on, and you may survive
without these 100-1000-600 guesses.

I gather you put your forwarding procedure ForwardIrpDirectly in
a WorkItem, as opposed to your own [system] thread, right?

If yes, then here is what happens: there are only as many system
workers in a pool [two on a single processor system, IIRC], and
pretty soon all these workers find themselves in your waits,
but the kernel [and other drivers] need these workers
also - you are not the only one who uses WorkItems.

Voila: 100% of the [system] thread pool sits in your waits, the system
is almost dead, congratulations.

Try to create your own thread [in other words, no work items], process
your forwarding from it [with obvious interlocking of your dequeue,
of course] and see what happens.

You may want to look for a sample of how this is done in the infamous
filedisk sample.

[ Jamey Kirby did one good thing, wrote this code, and one bad thing,
created an energy drink called “Cocaine”. Bo Branten - allegedly! -
stole the code - but not the drink - and published it under GPL.

You can still learn from Kirby’s code.

Do not learn from his business experience though:-) ]

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, February 13, 2009 11:28 PM
Subject: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Thank you for replies.
>
>>…until the boot is over
> Is there a way to determine when is the system fully loaded?
>
> Thanks again.
>
> Arthur
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · February 14, 2009, 11:33am

Indeed, ForwardIrpDirectly is called directly from IRP_MJ_WRITE when IRQL is PASSIVE_LEVEL.
Those wrappers for critical regions I borrowed from a microsoft article about driver security. Also, all mutex related functions use such wrappers internally. Anyway, it seems the issue is not in them and I’ll probably remove that code. I thought there is could be a special event which can say when boot is finished and the system is ready to “serve” :).

Thanks!

Doron_Holan · February 14, 2009, 11:46am

The critical region calls are important if you are waiting in the context of a user mode thread. By using these calls you prevent the app from being able to inifinitely suspend the thread. This is important if you have acquired a driver lock b/c the lock will then never be released, alowing a low privileged app a way to hang or control your driver.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Alex Shvedov
Sent: Saturday, February 14, 2009 5:39 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Is there a way to determine when is the system fully loaded?
My guess would be that there is no such thing (what is “fully”?)

Cheap and dirty [but I am not saying that this cannot be used
in production]: try saving 100 irps, if the boot is still long,
try 1000, if boot is fast, try 500 etc.

In my case a queue of 600 was long enough, but I may be wrong.

Two more things, however:

1. You disable the delivery of normal kernel APCs [special
kernel-mode APCs are still delivered] by wrapping
KeWaitForSingleObject by a KeEnter/LeaveCriticalRegion pair.

Why? What for?

From http://www.osronline.com/DDKx/kmarch/k105_40c2.htm:
“A thread is never alerted, nor is its wait aborted, by the delivery
of a kernel-mode APC.”

And since you have the 4th parameter of a wait (Alertable) set
to FALSE, user-mode APCs do not break the wait either.

So - what are you trying to achieve here?

Alertable = FALSE was good enough for me without these
wrappers.

2. Here is my guess on what really goes on, and you may survive
without these 100-1000-600 guesses.

I gather you put your forwarding procedure ForwardIrpDirectly in
a WorkItem, as opposed to your own [system] thread, right?

If yes, then here is what happens: there are only as many system
workers in a pool [two on a single processor system, IIRC], and
pretty soon all these workers find themselves in your waits,
but the kernel [and other drivers] need these workers
also - you are not the only one who uses WorkItems.

Voila: 100% of the [system] thread pool sits in your waits, the system
is almost dead, congratulations.

Try to create your own thread [in other words, no work items], process
your forwarding from it [with obvious interlocking of your dequeue,
of course] and see what happens.

You may want to look for a sample of how this is done in the infamous
filedisk sample.

[Jamey Kirby did one good thing, wrote this code, and one bad thing,
created an energy drink called “Cocaine”. Bo Branten - allegedly! -
stole the code - but not the drink - and published it under GPL.

You can still learn from Kirby’s code.

Do not learn from his business experience though:-)]

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, February 13, 2009 11:28 PM
Subject: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Thank you for replies.
>
>>…until the boot is over
> Is there a way to determine when is the system fully loaded?
>
> Thanks again.
>
> Arthur
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · February 14, 2009, 12:03pm

It means I can safely remove them.

Thank you.

OSR_Community_User · February 14, 2009, 1:20pm

> The critical region calls are important if you are waiting in the context

of a user mode thread.
If OP is going to follow my advice, it is not going to be the case
automatically, the thread
will run in system context.

By using these calls you prevent the app from being able to infinitely
suspend the thread.
I am loosing you here.

I would say on the contrary, a [potentially infinite] wait wrapped into
KeEnter/LeaveCriticalRegion pair cannot be interrupted:
“KeEnterCriticalRegion routine
temporarily disables the delivery of normal kernel APCs” (WDK).

To continue the quote, “special kernel-mode APCs are still delivered”, but
they don’t
break the wait.

What is it that I am missing?

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Saturday, February 14, 2009 11:47 AM
Subject: RE: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

The critical region calls are important if you are waiting in the context of
a user mode thread. By using these calls you prevent the app from being able
to inifinitely suspend the thread. This is important if you have acquired a
driver lock b/c the lock will then never be released, alowing a low
privileged app a way to hang or control your driver.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Alex Shvedov
Sent: Saturday, February 14, 2009 5:39 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Is there a way to determine when is the system fully loaded?
My guess would be that there is no such thing (what is “fully”?)

Cheap and dirty [but I am not saying that this cannot be used
in production]: try saving 100 irps, if the boot is still long,
try 1000, if boot is fast, try 500 etc.

In my case a queue of 600 was long enough, but I may be wrong.

Two more things, however:

1. You disable the delivery of normal kernel APCs [special
kernel-mode APCs are still delivered] by wrapping
KeWaitForSingleObject by a KeEnter/LeaveCriticalRegion pair.

Why? What for?

From http://www.osronline.com/DDKx/kmarch/k105_40c2.htm:
“A thread is never alerted, nor is its wait aborted, by the delivery
of a kernel-mode APC.”

And since you have the 4th parameter of a wait (Alertable) set
to FALSE, user-mode APCs do not break the wait either.

So - what are you trying to achieve here?

Alertable = FALSE was good enough for me without these
wrappers.

2. Here is my guess on what really goes on, and you may survive
without these 100-1000-600 guesses.

I gather you put your forwarding procedure ForwardIrpDirectly in
a WorkItem, as opposed to your own [system] thread, right?

If yes, then here is what happens: there are only as many system
workers in a pool [two on a single processor system, IIRC], and
pretty soon all these workers find themselves in your waits,
but the kernel [and other drivers] need these workers
also - you are not the only one who uses WorkItems.

Voila: 100% of the [system] thread pool sits in your waits, the system
is almost dead, congratulations.

Try to create your own thread [in other words, no work items], process
your forwarding from it [with obvious interlocking of your dequeue,
of course] and see what happens.

You may want to look for a sample of how this is done in the infamous
filedisk sample.

[Jamey Kirby did one good thing, wrote this code, and one bad thing,
created an energy drink called “Cocaine”. Bo Branten - allegedly! -
stole the code - but not the drink - and published it under GPL.

You can still learn from Kirby’s code.

Do not learn from his business experience though:-)]

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, February 13, 2009 11:28 PM
Subject: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Thank you for replies.
>
>>…until the boot is over
> Is there a way to determine when is the system fully loaded?
>
> Thanks again.
>
> Arthur
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Doron_Holan · February 14, 2009, 1:33pm

The point is not about blocking, it is about suspension. A suspension of a thread is implemented by delivering a normal APC to thread. In this particular case, it is just a wait on sync io. But if you are going to run more code after the wait is satisfied and the wait was on a resource that some other thread will try to acquire (eventually), a suspension apc can be delivered in this post wait code, thus orphaning the resource

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alex Shvedov
Sent: Saturday, February 14, 2009 10:20 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

The critical region calls are important if you are waiting in the context
of a user mode thread.
If OP is going to follow my advice, it is not going to be the case
automatically, the thread
will run in system context.

By using these calls you prevent the app from being able to infinitely
suspend the thread.
I am loosing you here.

I would say on the contrary, a [potentially infinite] wait wrapped into
KeEnter/LeaveCriticalRegion pair cannot be interrupted:
“KeEnterCriticalRegion routine
temporarily disables the delivery of normal kernel APCs” (WDK).

To continue the quote, “special kernel-mode APCs are still delivered”, but
they don’t
break the wait.

What is it that I am missing?

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Saturday, February 14, 2009 11:47 AM
Subject: RE: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

The critical region calls are important if you are waiting in the context of
a user mode thread. By using these calls you prevent the app from being able
to inifinitely suspend the thread. This is important if you have acquired a
driver lock b/c the lock will then never be released, alowing a low
privileged app a way to hang or control your driver.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Alex Shvedov
Sent: Saturday, February 14, 2009 5:39 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Is there a way to determine when is the system fully loaded?
My guess would be that there is no such thing (what is “fully”?)

Cheap and dirty [but I am not saying that this cannot be used
in production]: try saving 100 irps, if the boot is still long,
try 1000, if boot is fast, try 500 etc.

In my case a queue of 600 was long enough, but I may be wrong.

Two more things, however:

1. You disable the delivery of normal kernel APCs [special
kernel-mode APCs are still delivered] by wrapping
KeWaitForSingleObject by a KeEnter/LeaveCriticalRegion pair.

Why? What for?

From http://www.osronline.com/DDKx/kmarch/k105_40c2.htm:
“A thread is never alerted, nor is its wait aborted, by the delivery
of a kernel-mode APC.”

And since you have the 4th parameter of a wait (Alertable) set
to FALSE, user-mode APCs do not break the wait either.

So - what are you trying to achieve here?

Alertable = FALSE was good enough for me without these
wrappers.

2. Here is my guess on what really goes on, and you may survive
without these 100-1000-600 guesses.

I gather you put your forwarding procedure ForwardIrpDirectly in
a WorkItem, as opposed to your own [system] thread, right?

If yes, then here is what happens: there are only as many system
workers in a pool [two on a single processor system, IIRC], and
pretty soon all these workers find themselves in your waits,
but the kernel [and other drivers] need these workers
also - you are not the only one who uses WorkItems.

Voila: 100% of the [system] thread pool sits in your waits, the system
is almost dead, congratulations.

Try to create your own thread [in other words, no work items], process
your forwarding from it [with obvious interlocking of your dequeue,
of course] and see what happens.

You may want to look for a sample of how this is done in the infamous
filedisk sample.

[Jamey Kirby did one good thing, wrote this code, and one bad thing,
created an energy drink called “Cocaine”. Bo Branten - allegedly! -
stole the code - but not the drink - and published it under GPL.

You can still learn from Kirby’s code.

Do not learn from his business experience though:-)]

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, February 13, 2009 11:28 PM
Subject: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Thank you for replies.
>
>>…until the boot is over
> Is there a way to determine when is the system fully loaded?
>
> Thanks again.
>
> Arthur
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · February 14, 2009, 1:36pm

Great [as usual], thanks.

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Saturday, February 14, 2009 1:30 PM
Subject: RE: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

The point is not about blocking, it is about suspension. A suspension of a
thread is implemented by delivering a normal APC to thread. In this
particular case, it is just a wait on sync io. But if you are going to run
more code after the wait is satisfied and the wait was on a resource that
some other thread will try to acquire (eventually), a suspension apc can be
delivered in this post wait code, thus orphaning the resource

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alex Shvedov
Sent: Saturday, February 14, 2009 10:20 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> The critical region calls are important if you are waiting in the context
> of a user mode thread.
If OP is going to follow my advice, it is not going to be the case
automatically, the thread
will run in system context.

> By using these calls you prevent the app from being able to infinitely
> suspend the thread.
I am loosing you here.

I would say on the contrary, a [potentially infinite] wait wrapped into
KeEnter/LeaveCriticalRegion pair cannot be interrupted:
“KeEnterCriticalRegion routine
temporarily disables the delivery of normal kernel APCs” (WDK).

To continue the quote, “special kernel-mode APCs are still delivered”, but
they don’t
break the wait.

What is it that I am missing?

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Saturday, February 14, 2009 11:47 AM
Subject: RE: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

The critical region calls are important if you are waiting in the context of
a user mode thread. By using these calls you prevent the app from being able
to inifinitely suspend the thread. This is important if you have acquired a
driver lock b/c the lock will then never be released, alowing a low
privileged app a way to hang or control your driver.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Alex Shvedov
Sent: Saturday, February 14, 2009 5:39 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Is there a way to determine when is the system fully loaded?
My guess would be that there is no such thing (what is “fully”?)

Cheap and dirty [but I am not saying that this cannot be used
in production]: try saving 100 irps, if the boot is still long,
try 1000, if boot is fast, try 500 etc.

In my case a queue of 600 was long enough, but I may be wrong.

Two more things, however:

1. You disable the delivery of normal kernel APCs [special
kernel-mode APCs are still delivered] by wrapping
KeWaitForSingleObject by a KeEnter/LeaveCriticalRegion pair.

Why? What for?

From http://www.osronline.com/DDKx/kmarch/k105_40c2.htm:
“A thread is never alerted, nor is its wait aborted, by the delivery
of a kernel-mode APC.”

And since you have the 4th parameter of a wait (Alertable) set
to FALSE, user-mode APCs do not break the wait either.

So - what are you trying to achieve here?

Alertable = FALSE was good enough for me without these
wrappers.

2. Here is my guess on what really goes on, and you may survive
without these 100-1000-600 guesses.

I gather you put your forwarding procedure ForwardIrpDirectly in
a WorkItem, as opposed to your own [system] thread, right?

If yes, then here is what happens: there are only as many system
workers in a pool [two on a single processor system, IIRC], and
pretty soon all these workers find themselves in your waits,
but the kernel [and other drivers] need these workers
also - you are not the only one who uses WorkItems.

Voila: 100% of the [system] thread pool sits in your waits, the system
is almost dead, congratulations.

Try to create your own thread [in other words, no work items], process
your forwarding from it [with obvious interlocking of your dequeue,
of course] and see what happens.

You may want to look for a sample of how this is done in the infamous
filedisk sample.

[Jamey Kirby did one good thing, wrote this code, and one bad thing,
created an energy drink called “Cocaine”. Bo Branten - allegedly! -
stole the code - but not the drink - and published it under GPL.

You can still learn from Kirby’s code.

Do not learn from his business experience though:-)]

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, February 13, 2009 11:28 PM
Subject: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

> Thank you for replies.
>
>>…until the boot is over
> Is there a way to determine when is the system fully loaded?
>
> Thanks again.
>
> Arthur
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Mark_Roddy · February 14, 2009, 3:04pm

Depends on what you mean by that.
As a boot driver you can register for two series of driver entry callbacks
that roughly approximate the boot process.
See IoRegisterBootDriverReinitialization
and IoRegisterDriverReinitialization. Neither of these get you to ‘user mode
is available’. For that state you need a helper service that calls your
driver. Make that service dependent on whatever other services you think
ought to be up and running to constitute “system fully loaded” and have your
service send your driver an IOCTL.

Mark Roddy

On Fri, Feb 13, 2009 at 11:28 PM, wrote:

> Thank you for replies.
>
> >…until the boot is over
> Is there a way to determine when is the system fully loaded?
>
> Thanks again.
>
> Arthur
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

OSR_Community_User · February 14, 2009, 5:38pm

Thanks!

OSR_Community_User · February 17, 2009, 10:33am

The delayed initialization helped to start the Windows. But after 1-2 minutes the system hangs and I am getting the following:

kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8089da00) Shared 1 owning threads
Contention Count = 1
Threads: 867f0db0-01<*>
KD: Scanning for held locks…

Resource @ Ntfs!NtfsData (0xf71a25b0) Shared 1 owning threads
Contention Count = 2
Threads: 867f23f0-01<*>
KD: Scanning for held locks.

Resource @ 0x866e0c2c Shared 10 owning threads
Contention Count = 21
Threads: 85ee9020-01<*> 85ee9c58-01<*> 8651dc80-01<*> 867f2b40-01<*>
86623220-01<*> 8654bdb0-01<*> 864fb568-01<*> 8657cdb0-01<*>
862238d0-01<*> 85eb7b80-01<*>

Resource @ 0x866e0c64 Shared 1 owning threads
Threads: 867f1020-01<*>
KD: Scanning for held locks.

Resource @ 0x866d9e68 Shared 1 owning threads
Contention Count = 12
NumberOfSharedWaiters = 6
NumberOfExclusiveWaiters = 3
Threads: 867f28d0-01<*> 85ee9c58-01 8651dc80-01 8654bdb0-01
864fb568-01 862238d0-01 85eb7b80-01
Threads Waiting On Exclusive Access:
85ee9020 867f2b40 86623220

I suspect deadlock, the process are:

85ee9020: explorer.exe
867f2b40: VMwareService.exe

kd> !thread 867f2b40
THREAD 867f2b40 Cid 0004.0020 Teb: 00000000 Win32Thread: 00000000 WAIT: (Unknown) KernelMode Non-Alertable
86593c38 SynchronizationEvent
867f2bb8 NotificationTimer
IRP List:
87406e00: (0006,01fc) Flags: 40000884 Mdl: 00000000
Not impersonating
DeviceMap e1001140
Owning Process 867f47a8 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 17795 Ticks: 154 (0:00:00:02.406)
Context Switch Count 206
UserTime 00:00:00.000
KernelTime 00:00:00.000
Start Address nt!ExpWorkerThread (0x8087acfe)
Stack Init f78c7000 Current f78c6584 Base f78c7000 Limit f78c4000 Call 0
Priority 13 BasePriority 13 PriorityDecrement 0
ChildEBP RetAddr Args to Child
f78c659c 8082ffd7 867f2b40 867f2be8 00000000 nt!KiSwapContext+0x25 (FPO: [Uses EBP] [0,0,4])
f78c65b4 808287d4 867f2b40 866d9e68 00000000 nt!KiSwapThread+0x83 (FPO: [Non-Fpo])
f78c65f8 80877a75 86593c38 0000001b 00000000 nt!KeWaitForSingleObject+0x2e0 (FPO: [Non-Fpo])
f78c6634 80877c20 00000000 e16ca008 f78c6654 nt!ExpWaitForResource+0xd3 (FPO: [Non-Fpo])
f78c6644 f71865b4 866d9e68 86699601 f78c6678 nt!ExAcquireResourceExclusiveLite+0x6e (FPO: [Non-Fpo])
f78c6654 f71c33b1 866996d8 e16ca008 86699601 Ntfs!NtfsAcquireResourceExclusive+0x20 (FPO: [Non-Fpo])
f78c6678 f71c6c81 86699601 e16ca008 00000000 Ntfs!NtfsAcquireExclusiveFcb+0x42 (FPO: [Non-Fpo])
f78c66a4 f71b7222 866996d8 e16ca008 00000000 Ntfs!NtfsAcquireFcbWithPaging+0x7f (FPO: [Non-Fpo])
f78c67d8 f71c6ef8 866996d8 87406e00 f78c6818 Ntfs!NtfsCommonCreate+0x76a (FPO: [Non-Fpo])
f78c68dc 809ad50c 866e0718 87406e00 80a55c86 Ntfs!NtfsFsdCreate+0x17d (FPO: [Non-Fpo])
f78c690c 8081d591 f724c458 f78c6944 f724c458 nt!IovCallDriver+0x112 (FPO: [Non-Fpo])
f78c6918 f724c458 80a55c86 866e1668 866e1260 nt!IofCallDriver+0x13 (FPO: [Non-Fpo])
f78c6944 809ad50c 866e1668 87406e00 861faaf8 fltmgr!FltpCreate+0xe4 (FPO: [Non-Fpo])
f78c6974 8081d591 808f0f1b f78c6a68 808f0f1b nt!IovCallDriver+0x112 (FPO: [Non-Fpo])
f78c6980 808f0f1b f78c6b28 867b9018 00000000 nt!IofCallDriver+0x13 (FPO: [Non-Fpo])
f78c6a68 8092f71c 867b9030 00000000 864fe298 nt!IopParseDevice+0xa35 (FPO: [Non-Fpo])
f78c6ae8 8092b85c 00000000 f78c6b28 00000240 nt!ObpLookupObjectName+0x5b0 (FPO: [Non-Fpo])
f78c6b3c 808e2de7 00000000 00000000 6c694600 nt!ObOpenObjectByName+0xea (FPO: [Non-Fpo])
f78c6bb8 808e4081 f78c6cf8 00000080 f78c6c90 nt!IopCreateFile+0x447 (FPO: [Non-Fpo])
f78c6c14 808e7c11 f78c6cf8 00000080 f78c6c90 nt!IoCreateFile+0xa3 (FPO: [Non-Fpo])
f78c6c54 ba60c710 f78c6cf8 00000080 f78c6c90 nt!NtOpenFile+0x27 (FPO: [Non-Fpo])
f78c6d48 ba5eb7f9 867f2b40 861e8c80 865118b8 srv!CheckDiskSpace+0x1b5 (FPO: [Non-Fpo])
f78c6d6c 808e41ad 861e8c80 00000000 808a76c0 srv!ScavengerThread+0x8d (FPO: [Non-Fpo])
f78c6d80 8087ade9 865118b8 00000000 867f2b40 nt!IopProcessWorkItem+0x13 (FPO: [Non-Fpo])
f78c6dac 809418f4 865118b8 00000000 00000000 nt!ExpWorkerThread+0xeb (FPO: [Non-Fpo])
f78c6ddc 80887f7a 8087acfe 00000000 00000000 nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Does anyone knows what can cause this?

Thanks again,

Arthur

OSR_Community_User · February 17, 2009, 10:44am

I am sorry, I forgot to ask. In this particular case I should wait in my ForwardIrpDirectly() method with Alertable=TRUE, correct?

KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);

Thanks,

Arthur

Scott_Noone_OSR · February 17, 2009, 10:53am

The thread you showed doesn’t really matter, it’s just sitting waiting on a
lock.

Tracking down a deadlock always comes down to one question: “who owns the
resource everyone wants and why are they not releasing it” (“resource” here
being a general term). From this output 867f28d0 is the only thread of
interest as it owns a lock that other threads are waiting on.

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> The delayed initialization helped to start the Windows. But after 1-2
> minutes the system hangs and I am getting the following:
>
> kd> !locks
> DUMP OF ALL RESOURCE OBJECTS
> KD: Scanning for held locks…
>
> Resource @ nt!CmpRegistryLock (0x8089da00) Shared 1 owning threads
> Contention Count = 1
> Threads: 867f0db0-01<>
> KD: Scanning for held locks…
>
> Resource @ Ntfs!NtfsData (0xf71a25b0) Shared 1 owning threads
> Contention Count = 2
> Threads: 867f23f0-01<>
> KD: Scanning for held locks.
>
> Resource @ 0x866e0c2c Shared 10 owning threads
> Contention Count = 21
> Threads: 85ee9020-01<> 85ee9c58-01<> 8651dc80-01<> 867f2b40-01<>
> 86623220-01<> 8654bdb0-01<> 864fb568-01<> 8657cdb0-01<>
> 862238d0-01<> 85eb7b80-01<>
>
> Resource @ 0x866e0c64 Shared 1 owning threads
> Threads: 867f1020-01<>
> KD: Scanning for held locks.
>
> Resource @ 0x866d9e68 Shared 1 owning threads
> Contention Count = 12
> NumberOfSharedWaiters = 6
> NumberOfExclusiveWaiters = 3
> Threads: 867f28d0-01<> 85ee9c58-01 8651dc80-01 8654bdb0-01
> 864fb568-01 862238d0-01 85eb7b80-01
> Threads Waiting On Exclusive Access:
> 85ee9020 867f2b40 86623220
>
> I suspect deadlock, the process are:
>
> 85ee9020: explorer.exe
> 867f2b40: VMwareService.exe
>
> kd> !thread 867f2b40
> THREAD 867f2b40 Cid 0004.0020 Teb: 00000000 Win32Thread: 00000000 WAIT:
> (Unknown) KernelMode Non-Alertable
> 86593c38 SynchronizationEvent
> 867f2bb8 NotificationTimer
> IRP List:
> 87406e00: (0006,01fc) Flags: 40000884 Mdl: 00000000
> Not impersonating
> DeviceMap e1001140
> Owning Process 867f47a8 Image: System
> Attached Process N/A Image: N/A
> Wait Start TickCount 17795 Ticks: 154 (0:00:00:02.406)
> Context Switch Count 206
> UserTime 00:00:00.000
> KernelTime 00:00:00.000
> Start Address nt!ExpWorkerThread (0x8087acfe)
> Stack Init f78c7000 Current f78c6584 Base f78c7000 Limit f78c4000 Call 0
> Priority 13 BasePriority 13 PriorityDecrement 0
> ChildEBP RetAddr Args to Child
> f78c659c 8082ffd7 867f2b40 867f2be8 00000000 nt!KiSwapContext+0x25 (FPO:
> [Uses EBP] [0,0,4])
> f78c65b4 808287d4 867f2b40 866d9e68 00000000 nt!KiSwapThread+0x83 (FPO:
> [Non-Fpo])
> f78c65f8 80877a75 86593c38 0000001b 00000000
> nt!KeWaitForSingleObject+0x2e0 (FPO: [Non-Fpo])
> f78c6634 80877c20 00000000 e16ca008 f78c6654 nt!ExpWaitForResource+0xd3
> (FPO: [Non-Fpo])
> f78c6644 f71865b4 866d9e68 86699601 f78c6678
> nt!ExAcquireResourceExclusiveLite+0x6e (FPO: [Non-Fpo])
> f78c6654 f71c33b1 866996d8 e16ca008 86699601
> Ntfs!NtfsAcquireResourceExclusive+0x20 (FPO: [Non-Fpo])
> f78c6678 f71c6c81 86699601 e16ca008 00000000
> Ntfs!NtfsAcquireExclusiveFcb+0x42 (FPO: [Non-Fpo])
> f78c66a4 f71b7222 866996d8 e16ca008 00000000
> Ntfs!NtfsAcquireFcbWithPaging+0x7f (FPO: [Non-Fpo])
> f78c67d8 f71c6ef8 866996d8 87406e00 f78c6818 Ntfs!NtfsCommonCreate+0x76a
> (FPO: [Non-Fpo])
> f78c68dc 809ad50c 866e0718 87406e00 80a55c86 Ntfs!NtfsFsdCreate+0x17d
> (FPO: [Non-Fpo])
> f78c690c 8081d591 f724c458 f78c6944 f724c458 nt!IovCallDriver+0x112 (FPO:
> [Non-Fpo])
> f78c6918 f724c458 80a55c86 866e1668 866e1260 nt!IofCallDriver+0x13 (FPO:
> [Non-Fpo])
> f78c6944 809ad50c 866e1668 87406e00 861faaf8 fltmgr!FltpCreate+0xe4 (FPO:
> [Non-Fpo])
> f78c6974 8081d591 808f0f1b f78c6a68 808f0f1b nt!IovCallDriver+0x112 (FPO:
> [Non-Fpo])
> f78c6980 808f0f1b f78c6b28 867b9018 00000000 nt!IofCallDriver+0x13 (FPO:
> [Non-Fpo])
> f78c6a68 8092f71c 867b9030 00000000 864fe298 nt!IopParseDevice+0xa35 (FPO:
> [Non-Fpo])
> f78c6ae8 8092b85c 00000000 f78c6b28 00000240 nt!ObpLookupObjectName+0x5b0
> (FPO: [Non-Fpo])
> f78c6b3c 808e2de7 00000000 00000000 6c694600 nt!ObOpenObjectByName+0xea
> (FPO: [Non-Fpo])
> f78c6bb8 808e4081 f78c6cf8 00000080 f78c6c90 nt!IopCreateFile+0x447 (FPO:
> [Non-Fpo])
> f78c6c14 808e7c11 f78c6cf8 00000080 f78c6c90 nt!IoCreateFile+0xa3 (FPO:
> [Non-Fpo])
> f78c6c54 ba60c710 f78c6cf8 00000080 f78c6c90 nt!NtOpenFile+0x27 (FPO:
> [Non-Fpo])
> f78c6d48 ba5eb7f9 867f2b40 861e8c80 865118b8 srv!CheckDiskSpace+0x1b5
> (FPO: [Non-Fpo])
> f78c6d6c 808e41ad 861e8c80 00000000 808a76c0 srv!ScavengerThread+0x8d
> (FPO: [Non-Fpo])
> f78c6d80 8087ade9 865118b8 00000000 867f2b40 nt!IopProcessWorkItem+0x13
> (FPO: [Non-Fpo])
> f78c6dac 809418f4 865118b8 00000000 00000000 nt!ExpWorkerThread+0xeb (FPO:
> [Non-Fpo])
> f78c6ddc 80887f7a 8087acfe 00000000 00000000
> nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> Does anyone knows what can cause this?
>
> Thanks again,
>
> Arthur
>

Doron_Holan · February 17, 2009, 11:10am

No, the wait should not be alertable

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@cogeco.ca
Sent: Tuesday, February 17, 2009 7:46 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

I am sorry, I forgot to ask. In this particular case I should wait in my ForwardIrpDirectly() method with Alertable=TRUE, correct?

KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);

Thanks,

Arthur

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · February 17, 2009, 11:15am

> The delayed initialization helped to start the Windows. But after 1-2

minutes the system hangs
Did you try a dedicated thread?

I should wait in my ForwardIrpDirectly() method with Alertable=TRUE,
correct?
No, leave it FALSE.
You want to wait until your operation is completed and you do not want
the wait to be interrupted on anything else (= APC).

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, February 17, 2009 10:43 AM
Subject: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

>I am sorry, I forgot to ask. In this particular case I should wait in my
>ForwardIrpDirectly() method with Alertable=TRUE, correct?
>
> KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);
>
> Thanks,
>
> Arthur
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · February 17, 2009, 11:26am

> The delayed initialization helped to start the Windows. But after 1-2

minutes the system hangs
>Did you try a dedicated thread?
We need to make sure all write events have been traced even during the BSOD and the shutdown process (some write events are comming after IRP_MJ_SHUTDOWN). And it seems we are loosing them if we use a dedicated thread.

Thanks.

OSR_Community_User · February 17, 2009, 11:48am

> And it seems we are loosing them if we use a dedicated thread.
No, you do not, or, to be exact, not more than if you use
system-provided worker thread pool, the one that serves
WorkItems.

You can not guarantee it anyway (what if someone pulls out the power
cord?), what you can do is to keep a flag “I flushed queue ok” that

when not set - will at least tell you “something went very wrong
before”.

This flag should be peristent, of course, and I had to do some
tricks to make it happen, but you can postpone this, make it work
w/o slowing down the OS first.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, February 17, 2009 11:25 AM
Subject: RE:[ntdev] IoBuildSynchronousFsdRequest delays boot time.

>> The delayed initialization helped to start the Windows. But after 1-2
>> minutes the system hangs
>>>Did you try a dedicated thread?
> We need to make sure all write events have been traced even during the
> BSOD and the shutdown process (some write events are comming after
> IRP_MJ_SHUTDOWN). And it seems we are loosing them if we use a dedicated
> thread.
>
> Thanks.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer