Is there any "Boot session ID" or (reliable) "Boot timestamp"?
For an installation I need to detect that a scheduled reboot took place indeed.
I guess I could do a dummy MoveFileEx() with MOVEFILE_DELAY_UNTIL_REBOOT, but i did hope for something easier.
(We have to install a 3rd party package that sometimes behaves erratically after an repair/update. In that state, accessing the device may even lock up the system)
(Windows XP, Vista, 7)
For things like this, WMI (Windows Management Instrumentation) is often a good starting place. I know you can get current uptime directly through it, which may allow you to determine if a machine recently rebooted.
Here is a blog post with some code samples as well:
http://blogs.technet.com/heyscriptingguy/archive/2004/09/07/how-can-i-tell-if-a-server-has-rebooted.aspx
Depending on your implementation language, you probably just want to pull out the query code from the vbscript.
Apparently Windows has the equivalent of "uptime". Here's more info: http://support.microsoft.com/kb/555737
As I understand it, this should tell you how long ago the system was booted. Will that information solve your problem?
You could search the System event log for event 6009 from the EventLog source - this is the first event recorded after each reboot.
I think the best answer has already been given here: Find out if computer rebooted since the last time my program ran?
That seems to be the simplest way. Use GlobalFindAtom() to see if it exists and create it, with GlobalAddAtom(), if it doesn't. It will persist beyond the execution of your program. If your application runs again, and sees that the atom exists, then then it isn't the first run since reboot.
If the computer is restarted, then the atom won't exist, indicating that this is the first run of your program since the reboot.
Related
Yesterday I ran a BIOS update on a Windows7 computer. The BIOS update tool performed a shutdown of Windows and without restarting the computer (so directly after Windows shutdown), a DOS-like tool started that updated the BIOS.
I searched the WWW but all I can find is how to execute applications at Windows shutdown (so before windows goes down) or at logoff (logoff scripts).
Does anyone have any clue on how to achieve this?
It is my guess that the machine had in fact performed a soft-reboot and was running BIOS code. That's the usual approach, and in some cases the soft-reboot may not be visible to the user, i.e., the BIOS self-update code may run before the POST.
However, it is (or at least used to be) possible to run Windows code post-shutdown, although obviously it is limited in what it can do. The key information can be found in the MSDN library entry on the Service Control Handler Function:
After this time expires, system shutdown proceeds regardless of whether service shutdown is complete. Note that if the system is left in the shutdown state (not restarted or powered down), the service continues to run.
So, at least in principle, all you need to do is to install a service that asks for shutdown notification but does not actually stop when shutdown occurs, and then instruct Windows to shut down without rebooting or powering off. I have actually seen this happen, but only on older versions of Windows (before automatically powering off at shutdown became the default!) so I can't guarantee that it still works, although it definitely did once.
It should, however, be noted that this will not necessarily give you the sort of environment you may be thinking of. For example, device drivers are not necessarily unloaded before shutdown; after all, what would be the point?
You can run Local Group policy - gpedit.msc (From run).
Under Computer Configuration choose Windows Settings
choose Scripts(Startup/Shutdown)
On Shutdown properties you can add script and also mention parameters if needed.
I also advised you to look at the following question - how to delay shutdown and run a process in window service
After intensive searching why certain workstations wouldn't perform a certain action when just being started up in the morning (...) I've discovered that GetPrivateProfileInt just returns the default value and doesn't bother to set GetLastError to something non-zero when the network-subsystem hasn't activated yet (e.g. because the DHCP client is still trying to get hold of an IP address to use.)
Does this sound familiar to someone? Does anybody happen to know what I should/could do about it?
For now I'll correct by using an alternate default value, and stalling a bit while I get my default value.
GetPrivateProfileInt() is one of those innocent looking Windows API functions that has a ton of code behind it. There's a mass of appcompat code, designed to allow Win3 programs to run on modern versions of Windows. One of the side-effects is that it is incredibly slow, it took about 50 msec the last time I profiled it.
Looks like you found a flaw in it. For all I know, it might actually be designed appcompat behavior. Emulating the way this API worked 18 years ago. I have no clue of course if that's accurate.
The very best thing you can do is stop using it. A possible workaround is to open the file first so that your program blocks until the service is up and running.
I would check if the file exists and sleep for a few seconds until the file is there. After some number of tries either use the default value or take an appropriate action.
Windows 7 is caching some of the COM class information. Older OSs didn't do this. After the OS looks up theHKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value, it caches the value, and doesn't look it up again.
When we update our software, we place the new updates in a different directory, and then update the HKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value to reflect the new path. The next time the software runs, it will use the latest files if running under older Windows OSs. However, on Windows 7, it will continue to use the older file, until the OS is rebooted.
I ran process monitor, and discovered that under Windows 7, it never reads the registry key again, after the first read. On older OSs, it reads that key every time.
My question is: Is there any way to force Windows 7 to re-read the LocalServer32 information from the HKCU hive each time a new out of proc COM object is created?
I have only been able to solve this problem by...
1: Stopping the Process
2: explicitly unregistering using regsvr32 the library ( or exename /unregserver)
3: Registering the new component
4: Starting the process back up.
I would suspect that it is the Un Reg part that is failing for you. If you are just changing the registry key directly then you should call RegSvr32 /u instead.
Also make sure the new directory location is the current directory when you call RegSvr32.
Note that I have always stopped the process and then unregistered, this is probably a significant detail.
As this is a top result in Google for this narrow-ish problem, I thought it would be valuable to add my troubleshooting outcome for this problem.
I found this response on SO: C# : How to change windows registry and take effect immediately
And linked solution from that answer: Registry Watcher C#
Both of which seem viable options for managing changed keys without forcing a reboot. For us (like the OP) this was when installing updates. For us (possibly unlike the OP) this is infrequent and we decided the effort to implement and test a fix as described was outweighed by the simple solution of requiring a reboot: a process Windows users have come to expect with installing software anyway.
How can I find what's hanging all new installations on a Windows box?
While testing an installation script on Windows (XP Pro, if it matters) I've run into a situation wherein any and all attempts to install anything on the system hang waiting on who knows what. When the system is restarted, all queued up attempts at installation then go through their exit paths with pop-ups that report the installation is being aborted due to system shutdown having been requested. Of course, reboots do not cure the problem. The system otherwise runs fine.
So... How can I determine what part of the OS I've wedged? (Something in the registry, I suppose, but I'm a real greenhorn when it comes to Windows.) Most likely, something from a preceding install attempt went awry and is now blocking even though I saw no errors reported. Once I figure this out, I want to put in a check for this sort of thing, possibly at both ends of my install scripts, if that seems reasonable.
Thanks for your input.
UPDATE:
Unfortunately for me, rebuilding from scratch to get to the point the system's in now is about 9 hours. I'd like to unwedge it from where it is now rather than reload (again). Procmon seems great but I haven't got SP2 installed, only SP1! -frown- So, other ideas are welcome.
I assume you've tried logging the install to see where things go wrong?
Try rolling back to before things went wrong using "System Restore", if that doesn't solve it and the MSI log files show nothing useful then I'd take the plunge and reload before wasting any more time on it.
That said, if you're developing installers then taking an image of this PC in it's crappy state could be a worthwhile exercise. Some point in the future when you have more time to debug you can try and figure out what the problem is.
P.S. I'm assuming you're asking this question from the point of view of someone developing an installer and not as a tech-support question... otherwise this question should probably be closed as not-programming-related ;)
Try using Procmon to figure out where the installer is having problems, if you set a filter it will report all file and registry activity for that process.
I want Windows Update to automatically download and install updates on my Vista machine, however I don't want to be bothered by the system tray reboot prompts (which can, at best, only be postponed by 4 hours).
I have performed the registry hack described here to prevent Windows forcibly rebooting my machine, which is a good start. However, is there any way to get rid of the reboot prompts altogether, or decrease their frequency?
Not sure if it is the same for vista, but worth a try.
On Windows XP, you can modify a group policy setting to change how frequently it re-prompts you. (start -> run type gpedit.msc)
Look under Computer Configuration/Administrative Templates/Windows Components/Windows Update
The setting you want is called Re-Prompt for restart with scheduled installations.
The default is 10 minutes.
You can also try modifying the No auto-restart for scheduled Automatic Updates installations setting found in the same location.
Just turn off the Automatic Update service. It will restart the next time you reboot so you'll still get the updates done.
Running this in a command window will stop it until the next reboot.
sc stop wuauserv
I recommend disabling the auto update.
As a developer the last thing you need is to have random updates done to your workstation, especially while you are working. I set aside a time every month to go through the process manually. I avoid doing it if I am in the middle of testing something really important or up against an immediate deadline.
To clarify what ehogue said:
Start->Control Panel->Administrative Tools->Services->Automatic Updates->Right-click->Stop.
In Windows XP, after windows has been updated, I use the following trick: run this command
pssuspend wuauclt
pssuspend is a free sys-internals tool.
This way, you will not be prompted about restart.
I will risk some down-votes here by saying: this seems a little bit schizophrenic, though a lot of people ask for it.
If you want Windows to download and install the updates, but not complete the install process by rebooting - what's the point? Why not simply turn of AutoUpdates in the first place? if you don't even want the OS to tell you it would like to reboot, then how can you know that you need to, y'know, reboot?
Patches which call for a reboot are not fully active until that reboot is complete; thus your system remains vulnerable to the unpatched behaviour. If you are a human who goes to the bathroom or eats meals, I just do not understand the mentality of wanting to patch but then postpone the reboot for days, weeks, months. Better to stay unpatched!
just open taskmanager and right-click on "wuauclt.exe" en clcik stop or delete or something that should keep that program from running.