We are setting up an embedded Windows system which needs to have a function to change the system date and time. Our system does not shut down normally just like a normal PC, instead, the user will cut the power directly.
The problem comes when we tried to use the Win API function like SetLocalTime() (with admin rights), the API succeeded when the function just executed, but when the user restarts the machine (i.e. cut the power and turning it on again), the date setting is reverted back to the previous date setting. Looks like the OS cache the setting which requires a normal restart to store the setting to disk.
Does anyone know how to "flush the data cache" immediately without restarting the OS?
Thank you very much.
There are two workaround you can check to see if it helps:
After change Windows time you explicitly execute a reboot to enable your changes to be written to disk before the user cut the power directly. You can use the following API to reboot the system:
ExitWindowsEx(EWX_REBOOT | EWX_FORCE,
SHTDN_REASON_MAJOR_OPERATINGSYSTEM |
SHTDN_REASON_MINOR_UPGRADE |
SHTDN_REASON_FLAG_PLANNED)
Ref: "How to Shut Down the System"
Caching can be turned off for a file is opened by passing FILE_FLAG_NO_BUFFERING as a value for the dwFlagsAndAttributes parameter of CreateFile. When caching is disabled, all read and write operations directly access the physical disk. So you can store the time on a such file and read it when the system reboot and set it again(Starting an Scheduled task on System Boot).
Related
I want to detect current windows 10 update status programmatically.
I tried wuapi and it works well but there are some problems in wuapi.
First, it takes long time to get update information.
Second, it can not be used at offline.
Is there any other method to detect current windows 10 update status?
Is there any registry or system file to detect it?
I tried procmon to analyse but there are too many files and registries linked with windows udpate.
Thank you...
There is no documented way to access the search results that Automatic Updates is using (the results that the Windows Update page in Settings displays).
However, there are two things that might be of use to you:
You can use IAutomaticUpdatesResults::LastInstallationSuccessDate to immediately see the last time the computer installed updates successfully. If all you want to know is "Is this PC processing updates successfully?", then this may be all you need.
You can use a Windows Update API search to see what updates are needed. Here's a script you can use as a starting point. If you use this script as written, it will go online to find newly-released updates, which isn't what you want in your scenario. But you can set your IUpdateSearcher object's Online property to false before calling Search. Doing that will perform an offline scan, in which WU just re-evaluates the updates it already knows about. This will work offline and will also return faster results.
"COM API
The COM API is a good way to directly access Windows Update without having to parse logs. Applications of this API range from finding available updates on the computer to installing and uninstalling updates.
You could use the Microsoft.Update.Session class to run an update search and then count the number of updates available to see if there are any updates for the computer.
PowerShell Example:
$updateObject = New-Object -ComObject Microsoft.Update.Session
$updateObject.ClientApplicationID = "Serverfault Example Script"
$updateSearcher = $updateObject.CreateUpdateSearcher()
$searchResults = $updateSearcher.Search("IsInstalled=0")
Write-Host $searchResults.Updates.Count
If the returned result is more than 0 then there are updates for the computer that need to be installed and/or downloaded. You can easily update the powershell script to fit your application.
Just a heads up, it appears that the search function is not async so it would freeze your application while searching. In that case you will want to make it async."
Registry method
Source:
https://serverfault.com/questions/891188/is-it-possible-to-detect-the-windows-update-status-via-registry-to-see-if-the-s
I have followed this tutorial for developing an operating system. I am using Windows 10 as my host sytem and used wsl for compiling. But my VM fails as soon as I enable interrupts.
This is the log file of the VM that is output, but I cannot understand it. I am pretty naive with VirtualBox. Can someone explain any possible error you see?
Here is the code of the Os. I just have changed the structure I believe. Rest code in execution point of view is same as shown in video series.
That is a lot of log to scroll through and it's hard to be sure on the face of it that just looking at that would be able to tell us what about your startup code (not visible to us as part of the question) would trigger it. However, I can speak to some general strategies about approaching a log file like this.
We can see some general state transitions in there. The log ends with:
00:00:15.712045 Changing the VM state from 'DESTROYING' to 'TERMINATED'
So I can go back through and look at where the first instance of DESTROYING showed up, which was:
00:00:15.698320 Changing the VM state from 'POWERING_OFF' to 'OFF'
00:00:15.701802 Changing the VM state from 'OFF' to 'DESTROYING'
Following the same process backwards to POWERING_OFF, I see:
00:00:08.577363 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
00:00:14.342287 ERROR [COM]: aRC=VBOX_E_INVALID_VM_STATE (0x80bb0002) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Invalid machine state GuruMeditation when checking if the guest entered the ACPI mode)}, preserve=false aResultDetail=0
00:00:15.643579 GUI: Request for close-action to power VM off.
00:00:15.643599 GUI: Passing request to power VM off from machine-logic to UI session.
00:00:15.643606 GUI: Powering VM down on UI session power off request...
00:00:15.644257 Console: Machine state changed to 'Stopping'
00:00:15.644763 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Stopping, InUninit=0)
00:00:15.645075 Changing the VM state from 'GURU_MEDITATION' to 'POWERING_OFF'
That error line at the top of that block may point to something searchable that would turn up other instances of people having the same or a similar problem. If you scroll up a bit, you can also see that something VGA-related was happening right before the error, which may help narrow it down if it's directly related to the error, or may be another step to backtrack through on the way to the real issue.
I get the following error after upgrading via Migration Assistant my laptop from a 2-core to a 4-core processor:
cpum#1: X86_CPUID_FEATURE_ECX_MOVBE is not supported by the host but
has already exposed to the guest [ver=17 pass=final]
(VERR_SSM_LOAD_CPUID_MISMATCH).
How can i resolve the same?
The solution may be as simple as clicking the big yellow "Discard" button, which will delete the saved state (same as pulling the power cord).
Reference: https://forums.virtualbox.org/viewtopic.php?f=6&t=19351
For people working via a terminal.
The accepted answer correctly mentions to discard the current state of the VM. This basically means pull the power cord, so that the next time you start it, the machine reboots.
You can do this using
VBoxManage discardstate "your machine's name"
Click on the name of the virtual machine, right click on the menu and discard saved status
The Discard button worked for me. Thanks #Justin!
I've been chasing this exact error message off and on for months (fortunately my VM is not part of my daily work). The whole time I thought that it was an issue of being on a new CPU (based on CPUID_MISMATCH) so I was looking at how to move a VM from one CPU to another and how to change the expected CPUID. But everything I found in that searching required that you save and shut down properly on the original CPU, which I no longer have.
Simply "Discard"-ing the "Current State (changed)" version worked for me on all of my saved machines.
Whoda thunk that the fix for a virtual Windows machine was a hard reboot? Not like that works for hardware-based Windows boxes, right? ;-) I guess that's why they call rebooting "the Windows Panacea".
Thanks again.
I've tried the Win32_DesktopMonitor and checked the "Availability", but the value returned is always 3 (powered on), even when the monitor is physically turned off.
Is the data cached and there's a "force refresh" command in WMI, or in this particular case, the "Availability" is just not reliable ?
I think there is caching going on somewhere. I've observed it recently.
I wrote code that was polling for updates to Win32_PnPSignedDriver via SelectQuery / ManagementObjectSearcher and the results appear to be cached because it never realizes that a new device/driver has been added. Running the query from a separate app instantly sees that it was updated.
You may have a look to your driver. According to the documentation, starting with Windows Vista, hardware that is not compatible with Windows Display Driver Model (WDDM) returns inaccurate property values for instances of this class. For me it's an another way to say that it's not reliable.
Sometimes a network drive that is already mapped to a drive letter because "disconnected". Using the normal Windows functions to access files / folders on that drive fail. As soon as the user manually clicks on that drive it the Windows Explorer dialog, it's magically repaired.
Since my program is a batch program I'd like to start this "magic" from my program (C++) but I haven't found a Windows function for that. There's nothing in the usual WNet... functions...
NET USE V: /DELETE
NET USE V: "\\server1\videos"
NET USE L: /DELETE
NET USE L: "\\server2\archive"
When the path is inserted, you could check to see if it is a network resource and before opening files, use WNetGetConnection() to get the network resource.
You could also try to use WNetRestoreConnectionW(), which seems to have more spurious support, depending on the environment.
Try re-connecting to the share via net use:
net use \\server\folder [/user:[domain\]username] [password]
If that doesn't work, you can net use /delete it first, then re-connect.
Isn't this what WNetAddConnection and WNetAddConnection2 are for?
I suspect that is really the same thing, though. Explorer probably caches the connection info somewhere in the registry. When the user tries to go to that drive Explorer sees that the mapping is disconnected, reads the connection info from the registry, and re-creates the connection. Maybe you could try running regmon while you create a drive mapping and see if you can figure out where and how the connection information is cached.
I had trouble with this at a client of mine not long ago. I don't know if it's possible in your situation, but our fix was to tweak the Server's network settings to stop the timeouts and disconnects. See MSKB 297684 for details.
I agree with the comment from CMB, above. I've been down this path (excuse the pun) in the past and it caused me no end of trouble.
If the path is user configurable, they could use m:\pathonserver or they could use \server\c\pathonserver.
It shouldn't make any difference to your code, opening a file as m:\blahdeblah.dat or \server\c\blahdeblah.dat will be identical.
Using the UNC path is far more reliable, Windows will reconnect to that path automatically whether or not the mapped letter is there.
If you map a drive to a network
share, the mapped drive may be disconnected after a regular interval
of inactivity, and Windows Explorer may display a red "X" on the icon
of the mapped drive. However, if you try to access or browse the
mapped drive, it reconnects quickly.
To avoid this behavior use the following command:
net config server /autodisconnect:-1
Explanation of Microsoft on this topic:
https://support.microsoft.com/da-dk/help/297684/mapped-drive-connection-to-network-share-may-be-lost