This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(150.4, 88%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ES%3C/text%3E%3C/svg%3E)
Hello, not sure how much this forum gets browsed still. We still have devices using Embedded Standard 7 in the field. We have in the past year began enabling FBWF and RegFilter on them so as to reduce service calls for users that simply just unplug the device power and eventually we get blue screens. It seems to be the nature now with any appliance out there is to just unplug.
Anyway, I need to verify the correct RegFilter MonitoredKeys entries to allow any time changes, timezone changes, daylight savings changes. I've found some posts out there (even official ones) with the required RegFilter MonitoredKeys entries to allow to change these settings and not affect function.
I've found that we're having an issue since this most recent daylight savings change. What happens is the player reboots and the Windows time is set into the future, sometimes by as much as 3 hours (from the support issue I did today). Since the devices use encrypted communications, there cannot be too much time skew from the server or else the security cannot be negotiated, so essentially the device is operational but no communication. I didn't know what to do, and wasn't sure this was the cause even though I suspected it. All of a sudden the time on the device must've got synced automatically by the time server to the correct time and communications to servers were restored. We can't allow the device to sit in limbo because the time is different from the server too much.
Below are the RegFilters MonitoredKeys that I use, also included a couple links to the resources I used to find this information. I want to verify I have the correct ones or maybe I'm forgetting some.
As a side note, we've also noticed that joining Wi-Fi on some of our devices, upon rebooting, the Wi-Fi profile is not remembered and will not auto-join when FBWF and RegFilter is enabled. We have included the supposed Wi-Fi RegKeys that are needed, but apparently not the correct ones.
Also, I know Sean visits and answers a lot here, so I'm tagging him since this forum is very inactive as of late @Sean Liming
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\1]
"ClassKey"="HKLM"
"FileNameForSaving"="1.RGF"
"RelativeKeyName"="Software\\[RedactedCompanyName]"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\14]
"ClassKey"="HKLM"
"FileNameForSaving"="14.RGF"
"RelativeKeyName"="Software\\[RedactedCompanyName]"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\15]
"ClassKey"="HKLM"
"FileNameForSaving"="15.RGF"
"RelativeKeyName"="SYSTEM\\CurrentControlSet\\Control\\GraphicsDrivers"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\10]
"ClassKey"="HKLM"
"FileNameForSaving"="10.RGF"
"RelativeKeyName"="SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Time Zones"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\11]
"ClassKey"="HKLM"
"FileNameForSaving"="11.RGF"
"RelativeKeyName"="SYSTEM\\CurrentControlSet\\Control\\TimeZoneInformation"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\12]
"ClassKey"="HKLM"
"FileNameForSaving"="12.RGF"
"RelativeKeyName"="SYSTEM\\CurrentControlSet\\Control\\TimeZoneInformation\\RealTimeIsUniversal"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\13]
"ClassKey"="HKLM"
"FileNameForSaving"="13.RGF"
"RelativeKeyName"="SOFTWARE\\Wow6432Node\\[RedactedCompanyName]"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\2]
"ClassKey"="HKLM"
"FileNameForSaving"="2.RGF"
"RelativeKeyName"="Software\\Microsoft\\Windows\\CurrentVersion\\BITS\\StateIndex"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\3]
"ClassKey"="HKLM"
"FileNameForSaving"="3.RGF"
"RelativeKeyName"="Software\\Microsoft\\Windows NT\\CurrentVersion\\WinLogon"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\4]
"ClassKey"="HKLM"
"FileNameForSaving"="4.RGF"
"RelativeKeyName"="Software\\Microsoft\\Windows\\CurrentVersion\\Run"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\5]
"ClassKey"="HKLM"
"FileNameForSaving"="5.RGF"
"RelativeKeyName"="SOFTWARE\\Policies\\Microsoft\\Windows\\Wireless\\GPTWirelessPolicy"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\6]
"ClassKey"="HKLM"
"FileNameForSaving"="6.RGF"
"RelativeKeyName"="SOFTWARE\\Policies\\Microsoft\\Windows\\WiredL2\\GP_Policy"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\7]
"ClassKey"="HKLM"
"FileNameForSaving"="7.RGF"
"RelativeKeyName"="SYSTEM\\CurrentControlSet\\services\\Wlansvc"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\8]
"ClassKey"="HKLM"
"FileNameForSaving"="8.RGF"
"RelativeKeyName"="SYSTEM\\CurrentControlSet\\services\\WwanSvc"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\9]
"ClassKey"="HKLM"
"FileNameForSaving"="9.RGF"
"RelativeKeyName"="SYSTEM\\CurrentControlSet\\services\\dot3svc"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\_MachineAccount]
"ClassKey"="HKLM"
"FileNameForSaving"="_MachineAccount.RGF"
"RelativeKeyName"="SECURITY\\Policy\\Secrets\\$MACHINE.ACC"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RegFilter\Parameters\MonitoredKeys\_MSLicensing]
"ClassKey"="HKLM"
"FileNameForSaving"="_MSLicensing.RGF"
"RelativeKeyName"="Software\\Microsoft\\MSLicensing"
The UWF common filter exclusion page shows two keys for DST that you have already added to the exclusion list:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
Do you have the latest updates in the image?
Are you meaning Timezone specific hot fixes or just Windows update in general on the devices? If just Windows update, yes, the latest since FBWF was enabled. I know Microsoft has released Timezone hot fixes in the past to update daylight savings changes, etc. Is there a list of Win7 embedded standard Hot fixes that target time, daylight savings and timezone specifically?
To add to this, I've remoted into one of the machines having this issue and issued w32tm /resync command, which corrects the clock right there, but if I reboot, the time is off again.
Yes, I remember some specific DST issues, but I don't know the specific updates. It has been a while since I have worked with WES7. I suggest that you contact your Microsoft distributor to get more information. They can reach out to MS directly.
I forgot, did you set the BIOS time to UTC time? This was one of the suggestions in the old forum link your provided.
That's hard to know, these are in the field. Most likely they were set to local time when originally setup and the time changed on first setup. Does Windows actually change the BIOS time based on what is set within Windows? I don't know enough about the workings of this.
The device I have in the field right now I'm testing with (FBWF and RegFilter enabled), when I reboot it, the time is 1 hour ahead than it should be. Possibly because of the recent daylight time change of "spring forward", but when the sync command is run, it gets rolled back. I'm not sure what's causing Windows to think to add that additional 1 hour on boot time, and then syncing it brings it back, but rebooting it's still 1 hour ahead. I'm just confused too, because if I disable FBWF and reboot, when the time syncs again, then re-enabled FBWF and reboot all is fine I assume until the next daylight time change. Something is not persisting between reboots when FBWF is enabled?
When you reboot do you do a complete shutdown and restart? Or is the power pulled and powered plugged back in again?
Hi Sean, thanks for the reply. It's a normal reboot of the OS, no shutdown. Power is not pulled.
Right now I'm testing a potential workaround, we have a clock syncing and timezone setting routine (internal) within our bootup process that syncs the time and changes timezone based on what the server configuration tells it to. We had a check if FBWF was enabled, it would not do this because it would kick off a reboot, so essentially if we had this issue explained above it would be a reboot loop. We've disabled the reboot after a sync, and also moved this sync up a few steps within our boot process.
We also added a routine to "wait for internet" immediately when our main service would start, so the service knew there was internet available to sync the clock. With this change of our boot routine, we seem to have this working OK for our internal testings so far. We're doing more testing and configuration before we deploy this update out.
I really don't know what Windows was thinking, none of the Registry keys would be changed after a w32tm /resync either, I even did a registry compare program and didn't see any meaningful registry keys being updated anywhere else in the system after that. How having FBWF disabled and allowing a resync happen would persist over reboots has baffled me.
Then there must be some other key getting set, which is concerning since these two keys have been recommended for years.
It is a bit concerning for me too. For the FBWF, we have a write-through for this:
Volume: \Device\HarddiskVolume1 (C:) write-through: \Regfdata
Which should be sufficient. We have other registry keys persist across reboots like changes in display configuration.
I'm available to troubleshoot this more to try to narrow it down. Our workaround is OK, but if there is something that can be learned for the config, it may be worth it.
Yes. You should have set UTC Time and not update bios and than set your local timezone.