Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Re: [Q] What's the best way to calculate the # of milliseconds since boot?

Don_Burn_1Don_Burn_1 Member Posts: 4,311
How about

status = ZwQuerySystemInformation(3,&Systime,sizeof(Systime));

where systime is:

struct {
ULONG CurrentTimeZoneId;
} Systime;

This is from Gary Nebbett's excellent book "Windows NT/2000 Native
API Reference"

Don Burn
NT Device Driver and Filesystem Consulting

----- Original Message -----
From: "Matt A." <[email protected]>
To: "NT Developers Interest List" <[email protected]>
Sent: Tuesday, April 11, 2000 12:55 AM
Subject: [ntdev] [Q] What's the best way to calculate the # of milliseconds
since boot?

> Hello,
> At kernel-mode, how can I accurately -- at with at least as much
> resolution -- calculate the same value the user-mode function
> would return? This function returns the number of milliseconds since the
> system booted.
> I'm confused...
> KeQuerySystemTime() isn't any good because its not accurate enough (plus I
> don't know how to find out what time the system booted anyway --
> KeQuerySystemTime() returns a time relative to the year 1601).
> KeQueryInterruptTime/TickCount() with KeQueryTimeIncrement() don't *seem*
> any good because apparently (according to page 311 of Dekker & Newcomer)
> result of KeQueryTimeInterval() can vary with user-mode calls to
> timeBegin/EndPeriod(). Typically, the interval will be something like 10
> ms, but timeBeginPeriod(1) could change it 1 ms, for example, throwing off
> any calculations done with.
> And, as I understand it, this would seem to imply that the comment for
> KeQueryTickCount() that appears in the Windows 2000 DDK, "To determine the
> absolute elapsed time multiply the returned TickCount by the
> KeQueryTimeIncrement", is wrong. What's the deal?
> In any case, is the following (first stab) function actualy correct?
> ULONGLONG Get100NsUnitsSinceStartup()
> {
> return KeQueryInterruptTime();
> }
> If so, then I can just code the function I need like so, eh?
> DWORD GetMillisecondsSinceStartup()
> {
> return KeQueryInterruptTime() / 10000;
> }
> But, what if user-mode code calls timeBeginPeriod(1) to reduce the
> etc.? Does the value returned by KeQueryInterruptTime() increment at a
> higher rate then?
> Or, is the following function correct?
> LONGLONG Get100NsUnitsSinceStartup()
> {
> return KeQueryTickCount() * KeQueryTimeInterval();
> }
> And again, what if user-mode code calls timeBeginPeriod(1)? Will
> KeQueryTimeInterval() start returning smaller values?
> - Matt
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers 24 January 2022 Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online