Is HKLM \ SYSTEM \ CurrentControlSet \ Control \ TimeZoneInformation \ TimeZoneKeyName damaged?

Question

I am trying to determine the current time zone for a Windows system. The following code snippet (free) is based on @MattJohnson's answer on this topic: Getting the local timezone identifier when the OS display language is not English

using (RegistryKey registryKey = Registry.LocalMachine.OpenSubKey( @"SYSTEM\CurrentControlSet\Control\TimeZoneInformation")) { if (registryKey != null) { string windowsTimeZoneId = registryKey.GetValue("TimeZoneKeyName") as string; if (string.IsNullOrEmpty(windowsTimeZoneId)) windowsTimeZoneId = registryKey.GetValue("StandardName") as string; if (!string.IsNullOrEmpty(windowsTimeZoneId)) { int i = windowsTimeZoneId.IndexOf('\0'); if (i != -1) windowsTimeZoneId = windowsTimeZoneId.Remove(i); return ConvertFromWindowsId(windowsTimeZoneId); } } } 

If I put a breakpoint on the first line of "if (string.IsNullOrEmpty (windowsTimeZoneId)", then this is what I see in the Visual Studio debugger:

What's going on here? RegistryKey.GetValue () returns a string in a box, but why doesn't it detect two hex bytes and end the string there?

So far I have tested this on my two computers. This is the one that launches the 64-bit version of Windows 7. The other, running Windows 7 32-bit, is the same, except that it says that the length of the returned string is 128 characters instead of 127.

When viewing a registry entry using regedit.exe, this looks fine, showing only "Romantic Standard Time".

Googling raised this question a bit https://social.msdn.microsoft.com/Forums/sqlserver/en-US/eca7ad76-c910-46be-8fb9-876c7cde5c69/registry-read-time-zone-info-differ-when-code -build-on-40-framework-on-host-system-win-7-64-bit? forum = csharpgeneral Otherwise, I cannot find anything.

The program is built using Visual Studio 2012 and is aimed at .Net 2.0.

As you can see, I added the code to accept this “corrupt” result, but still I would appreciate it if someone could explain to me what is happening here, and maybe even how to avoid the whole problem.

EDIT:

The program is built using Visual Studio 2012 and is aimed at .Net 2.0.

Hmm, the plot is thickening. This statement was not entirely correct. The stump of the code shown above is in the library assembly, which is built for the target .NET 2.0, but it is called from a program aimed at .NET 4.0. Now I tried calling it from a program that targets .Net 2.0, and there is no problem, RegistryKey.GetValue () just returns "Romance Standard Time". This seems to have something to do with .Net Framework 4.0, which is implied by the publication on MSDN.

EDIT 2 - Started Thinking It Is "Normal"

This is a little off topic for SO, but I would appreciate if someone would take a look at my related post on Superuser.com, as I don't get instant satisfaction there, and I would like it to resolve, so I know should i still panic or not. Thanks.

https://superuser.com/questions/859031/possible-malware-modification-of-windows-registry-entry

Answer 1

When a registry value is set to string or multiline, Windows does not check semantics; it simply stores any binary content, with the length specified by the programmer. This means that the line may be prematurely terminated by zero or, conversely, not terminated by zero at all. (This, by the way, has security implications: although I don’t think that premature completion of null code can be a risk, there may be native code that cannot handle the case when the line does not have zero completion.)

According to Hans (in his deleted answer), .NET versions up to 4.x will ignore extra data if the line terminates prematurely with a null value, while 4.x turns it on. So, why did you only notice the problem after you started using 4.x.

As to why this particular value prematurely ends in zero, it looks carelessly on the Microsoft side. If you delete the additional data and then change the time zone, the additional data will reappear. So it looks like Windows itself is doing it. The data seems random to me, so I don’t think it is intentional. In fact, this can technically be a data vulnerability, although there is probably no practical impact.

I suggest you look for zero and trim the string if necessary. There may be situations when they are not there, for example, if the record was modified by third-party code or if MS eventually issues an update and fixes the problem, or, of course, if you are running .NET 2.x. Therefore, you will need to handle both cases.

(If I have time when I get back to work next week, I will install a blank copy of Windows on the virtual machine and confirm that the problem exists if there is absolutely no third-party software. If so, I will think about reporting about this - I doubt MS will release a patch, but it may be fixed in a future version of Windows.)