I believe that any driver install will trigger a checkpoint in system
restore.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jerry Schneider
Sent: Tuesday, May 09, 2006 2:42 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Updating Last Known Good b4 my install.
Peter Wieland wrote:
You only know Last-Known-Good is actually G by demonstrating that it
can boot the system. If you copy the registry at any arbitrary point
in time you may be declaring LK but there’s no reason to believe that
it’s G.
Before the era of “no-reboot” installs, LKG worked well because almost
any installation with a driver or service required a reboot, thus making
it unlikely that multiple installs would be undone by booting LKG.
In my case, I have a true boot-load (NTLDR) driver that, should it fail,
will more-or-less make the user’s system unbootable! It’s a
security-related driver that may occasionally fail if certain
poorly-coded, but difficult-to-detect rootkits are on a system. Because
the product is used in the enterprise, it itself must be a “no-reboot
installation” that cannot properly update the LKG.
If our driver should fail during install, or if the OS is later rebooted
and our driver should fail, we will recover the registry services to a
point before our installation (by manually or automatically rebooting to
the LKG, since a System Restore can’t be performed from a non-bootable
system.)
So what’s worse, trashing all of the no-reboot installs done before we
installed, or our setting the LKG to a state that may not be bootable? I
don’t think either are acceptable, but since System Restore isn’t
available on Win2K, one of these must occur on that OS.
System Restore is probably closer to what you’re trying to do anyway.
If something fails the user can reboot into safe-mode (assuming your
driver doesn’t load) and use SR to undo your driver update.
Agreed! What this confirms, however, is that the “no-reboot installs”
everybody (including Microsoft) wants us to do, are really just setting
the user up for a major hassle when a LKG reboot is required.
Any suggestions on how our installer might force a Restore Point
snapshot that can then automatically be restored from a LKG boot?
Talking end users through the manual System Restore process is daunting,
so it seems like I need a system restore Driver, NativeApp, or Service
that can automatically restore a specified snapshot from within a LKG
reboot.
I suppose for now all we can do is inform the user that they must reboot
or take a Restore point BEFORE they install any driver/service-based
product (to prevent the OS from trashing prior installations), and we
know that most users won’t reboot first. In any case, our product gets
blamed for the shortcomings of LKG.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jerry Schneider
Sent: Tuesday, May 09, 2006 10:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Updating Last Known Good b4 my install.
During the install of my package (app and drivers), I usually find
that the OS has recently been successfully rebooted. In some cases,
however, the install occurs on a platform that hasn’t been rebooted
for a long time, which means the Last Known Good (LKG) registry
snapshot does not include settings made by other product installations
that, for example, create a service during install but do not require
an immediate reboot.
This is only a problem if the drivers in my package need to restart in
LKG due to a serious compatibility conflict or other problem that
cannot be detected except at reboot.
What I need to do is something like creating a Recovery point before I
start my installation so that a reboot into LKG would remove only the
registy services created by my install. There is a documented
NotifyBootConfigStatus() API that claims to prompt the system to save
the current configuration as Last Known Good, but calling it during my
installation returns an error that the LKG has already been saved and
cannot be saved again.
A bit of research shows that this API (called from Winlogin)
communicates with SCM, and SCM waits until this call and all of the
autostart services are running
before calling NtInitializeRegistry() to (apparently) fork the
registry and save the current settings as LKG. The
NotifyBootConfigStatus() must be invoked from local System account or
an ACCESS_DENIED error occurs. Likewise, I presume, the
NtInitializeRegisty() call should be made from the Local System
account.
So is this the way to sync the LKG to the registry state before my
install?
From the somewhat limited undocumentation on NtInitializeRegistry, it
can be called with either a “setup” or “boot” mode parameter, but not
much else is available. Does this mean a hive file will be generated
for LKG, or will it just create a new SymLink in the registry or …
Any pointers on how to fix the LKG so it preserves changes made since
the last successful reboot would be appreciated (for W2K, XP, W2K3,
Vista …).
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer