title: Registry Changing When I Log Off (or On??)
body: <p><strong>Summary</strong></p>
  
  <p>I'm using C# .NET 4.0 Framework on 64 bit Windows 7 to write to the registry, and one of the values I write seems to change when I log off (or on, I can't tell), but only the first time I log off and back on.</p>
  
  <p>Please help me understand what I'm missing.</p>
  
  <p><strong>Full Story</strong></p>
  
  <p>Before we begin, there are valid reasons to do this, so please don't tell me "AH!! NEVER DO THIS!!" I understand that in the general case, this is not something you want to do to someone's computer. This is a controlled, limited distribution bound for specific machines that run embedded systems.</p>
  
  <p>With that caveat, I'm trying to programatically change the DPI to 96 and the window border width to very small. It seems I can do one or the other successfully, but doing them both stomps on each other. </p>
  
  <p>For testing, I use the Control Panel tool shown in the screenshot below to modify the DPI to the wrong settings, then run my program, snippets shown below.
  <img src="https://i.stack.imgur.com/VxjrX.png" alt="enter image description here"></p>
  
  <p>Here is the code:</p>
  
  <pre><code>       Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\\Control Panel\\Desktop\\WindowMetrics\\", "AppliedDPI", 0x60); // fix the DPI.
         Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\FontDPI", "LogPixels", 0x60);
         Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Hardware Profiles\\0000\\Software\\Fonts", "LogPixels", 0x60);
         Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Hardware Profiles\\0001\\Software\\Fonts", "LogPixels", 0x60);
         Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Hardware Profiles\\Current\\Software\\Fonts", "LogPixels", 0x60);
         Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\\Control Panel\\Desktop", "LogPixels", 0x60);
         Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\\Control Panel\\Desktop\\WindowMetrics\\", "BorderWidth", "-15"); // fix the border width.
         Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\\Control Panel\\Desktop\\WindowMetrics\\", "PaddedBorderWidth", "-15"); // fix the border width.
  </code></pre>
  
  <p>Now, in order for Windows 7 to actually apply these changes, I have to log off and back on. Prior to logging off, if I look in the registry, I see the values above all show up as I want them to. Once I log off and back on, <code>PaddedBorderWidth</code> has somehow become <code>-60</code> instead of <code>-15</code>. I don't think it has to do with <code>PaddedBorderWidth</code> being the last in the list. I tried it first with the same results.</p>
  
  <p>I think Windows 7 has some other Windows Theme thing that still has a hold on the window border width and is causing this on log on or log off. Once I log back on, if I run my C# program again, this time the setting sticks. Again this points me at a Windows Theme still holding on.</p>
  
  <p>I don't know why nor how to stop this. Can someone point me in the right direction?</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>Experimentally I have determined that the border width changes only when I change <code>"HKEY_CURRENT_USER\Control Panel\Desktop\LogPixels</code> and then log off and back on. Unfortunately, this is one of the keys I really need to change. It seems that changing <code>LogPixels</code> triggers some sort of border width default. Any thoughts?</p>
  
  <p>Again, I know this is a very non-standard thing to do, but such is life.</p>
  
  <p><strong>Workaround Update</strong>
  I worked around this issue by creating a small executable that sets these registry values when run as an elevated user. In the help file, the user is told to run this if the GUI doesn't look right, then they must log off and back on. If it still doesn't look right, they have to do it again, at which point, the settings will finally stick. </p>
  
  <p>While this "solves" the issue, it leaves me feeling extremely unsatisfied, as I feel there should be a nice, clean technical fix so the user <strong>never</strong> has to do this, but I'm out of time and have to ship. If anyone comes up with a better way, please speak up. I'd love to fix this for the next rev. </p>
  
  <p>Hopefully sometime in the future we can just fix the GUI to be DPI-aware, but that's much easier to say than do with this legacy code.</p>