Reboot since installed?

Yeah, it would be a little non-deterministic anyhow – might depend on the
speed of the disk, number of volumes, number of other drivers loaded, etc.,
etc.

Regardless, thanks for the thought.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Friday, January 27, 2006 6:09 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Reboot since installed?

well, on second thought - nevermind, I think the time difference would
be significantly smaller than what I initially thought
it would be.

MM wrote:

Crazy idea here, don’t know if this would work… I think you were
on the right track with system time.

From what I understand when a boot start driver is loaded, it’s driver
entry routine is called immediately. If the
FSFD is in the correct load order group, it will get loaded and
initialize before the file system. Now, using a global
variable to store the time the driver entry fired, vs when your volume
attach routine happens (which would only be after the FS is
initialized) there
should be a 10-20 second gap there (thus indicating to the driver’s
code a boot probably occurred).

Comparing this method to loading a filter while the system is running
using for example, the time between Driver_Entry
> and the volume attach routine would usually be under 1 sec. Thus,
> calculating this time gap and storing it in a var would indicate
> a boot start vs a fltmc load.
>
> Not 100%, but in theory I think it might work (most of the time)…
> Kinda a dynamic approach.
>
> As stated, still kinda new to this driver witting thing, so if this
> approach wouldn’t work at all, please do help me learn a little by
> explaining why…
>
> Hope I conveyed that right,
> Matt
>
>
>
> Ken Cross wrote:
>
>> NTFSD Folk:
>>
>> How can a driver determine if the system has been rebooted since it was
>> installed?
>>
>> There are a few operations that my driver needs to know that the
>> system has
>> been rebooted since the driver was installed, i.e., that the driver
>> started
>> before any applications have.
>>
>> I thought to use the time the driver started relative to the system boot
>> time, but that’s rather non-deterministic, e.g., within 30 seconds of
>> system
>> boot? 60 seconds? 5 minutes?
>>
>> (BTW, where is the system boot time kept in the kernel? I can’t find
>> it.)
>>
>> Ken
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@comcast.net
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

BTW, does anyone know where they keep the boot time in the kernel? I figure
it’s some global symbol somewhere, but I can’t find it.

FYI, I’ve tried KeQueryTickCount and KeQueryInterruptTime and subtract them
from KeQuerySystemTime to try to get the boot time, but something’s amiss –
the calculated boot time changes the longer the system is up (continues to
move backwards in time - weird).

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Friday, January 27, 2006 6:41 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Reboot since installed?

Yeah, it would be a little non-deterministic anyhow – might depend on the
speed of the disk, number of volumes, number of other drivers loaded, etc.,
etc.

Regardless, thanks for the thought.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Friday, January 27, 2006 6:09 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Reboot since installed?

well, on second thought - nevermind, I think the time difference would
be significantly smaller than what I initially thought
it would be.

MM wrote:

Crazy idea here, don’t know if this would work… I think you were
on the right track with system time.

From what I understand when a boot start driver is loaded, it’s driver
entry routine is called immediately. If the
FSFD is in the correct load order group, it will get loaded and
initialize before the file system. Now, using a global
variable to store the time the driver entry fired, vs when your volume
attach routine happens (which would only be after the FS is
initialized) there
should be a 10-20 second gap there (thus indicating to the driver’s
code a boot probably occurred).

Comparing this method to loading a filter while the system is running
using for example, the time between Driver_Entry
> and the volume attach routine would usually be under 1 sec. Thus,
> calculating this time gap and storing it in a var would indicate
> a boot start vs a fltmc load.
>
> Not 100%, but in theory I think it might work (most of the time)…
> Kinda a dynamic approach.
>
> As stated, still kinda new to this driver witting thing, so if this
> approach wouldn’t work at all, please do help me learn a little by
> explaining why…
>
> Hope I conveyed that right,
> Matt
>
>
>
> Ken Cross wrote:
>
>> NTFSD Folk:
>>
>> How can a driver determine if the system has been rebooted since it was
>> installed?
>>
>> There are a few operations that my driver needs to know that the
>> system has
>> been rebooted since the driver was installed, i.e., that the driver
>> started
>> before any applications have.
>>
>> I thought to use the time the driver started relative to the system boot
>> time, but that’s rather non-deterministic, e.g., within 30 seconds of
>> system
>> boot? 60 seconds? 5 minutes?
>>
>> (BTW, where is the system boot time kept in the kernel? I can’t find
>> it.)
>>
>> Ken
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@comcast.net
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Yeah, after thinking a little more about it didn’t seem like such a
great idea after all.

So the timing thing wouldn’t work, but would you be able to detect the
mount of the volume/device that
the OS’s is located on during a boot start, or is that not possible?

Curious, but what all can a fsf NOT see during a boot start? -
specifically between kernel initialization and FS initialization?
As I understand it, while the kernel is initializing and loading
drivers, the drivers are firing their entry points which set-up and
register their dispatch handlers. At what point do those dispatch
handlers become active where they can receive IRPs? Only
once the FS comes online or once the driver entry returns status_success?

Matt

Ken Cross wrote:

Yeah, it would be a little non-deterministic anyhow – might depend on the
speed of the disk, number of volumes, number of other drivers loaded, etc.,
etc.

Regardless, thanks for the thought.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Friday, January 27, 2006 6:09 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Reboot since installed?

well, on second thought - nevermind, I think the time difference would
be significantly smaller than what I initially thought
it would be.

MM wrote:

>Crazy idea here, don’t know if this would work… I think you were
>on the right track with system time.
>
>From what I understand when a boot start driver is loaded, it’s driver
>entry routine is called immediately. If the
>FSFD is in the correct load order group, it will get loaded and
>initialize before the file system. Now, using a global
>variable to store the time the driver entry fired, vs when your volume
>attach routine happens (which would only be after the FS is
>initialized) there
>should be a 10-20 second gap there (thus indicating to the driver’s
>code a boot probably occurred).
>
>
>Comparing this method to loading a filter while the system is running
>using for example, the time between Driver_Entry
>>and the volume attach routine would usually be under 1 sec. Thus,
>>calculating this time gap and storing it in a var would indicate
>>a boot start vs a fltmc load.
>>
>>Not 100%, but in theory I think it might work (most of the time)…
>>Kinda a dynamic approach.
>>
>>As stated, still kinda new to this driver witting thing, so if this
>>approach wouldn’t work at all, please do help me learn a little by
>>explaining why…
>>
>>Hope I conveyed that right,
>>Matt
>>
>>
>>
>>Ken Cross wrote:
>>
>>
>>
>>>NTFSD Folk:
>>>
>>>How can a driver determine if the system has been rebooted since it was
>>>installed?
>>>
>>>There are a few operations that my driver needs to know that the
>>>system has
>>>been rebooted since the driver was installed, i.e., that the driver
>>>started
>>>before any applications have.
>>>
>>>I thought to use the time the driver started relative to the system boot
>>>time, but that’s rather non-deterministic, e.g., within 30 seconds of
>>>system
>>>boot? 60 seconds? 5 minutes?
>>>
>>>(BTW, where is the system boot time kept in the kernel? I can’t find
>>>it.)
>>>
>>>Ken
>>>
>>>
>>>
>>>—
>>>Questions? First check the IFS FAQ at
>>>https://www.osronline.com/article.cfm?id=17
>>>
>>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>>
>>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>—
>Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

With the caveat that the \SystemRoot\ mount will never happen if the
entire storage stack leading to it isn’t already done initializing and
starting itself.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, January 27, 2006 12:18 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Reboot since installed?

In fact, in Boot driver init paths, no filesystems are accessible, and
only
the SYSTEM registry.

You can try accessing filesystem via \SystemRoot.… paths (thus
causing a
premature SystemRoot mount exactly at your file open), but this is
dangerous
and can cause numerous interop issues with other similar drivers. For
instance,
some of the Boot drivers by other vendors will not be able to monitor the
SystemRoot mount (its DriverEntry is not called yet), and so on.

System start phase is different from Boot phase only in that
\SystemRoot is
officially mounted (and some of the disk name symlinks are created), and
you
can access it.

This does not mean that you can use pathnames like ??\C:.…, or
non-SYSTEM registry hives. I would never ever use these things in init
paths
of any kernel module (though I would use them in IOCTL paths, which are
surely
called by my user-mode code when Windows is fully up).