How take ownership of an old Windows directory in the face of trustedinstaller, adobe, and the world

Having trouble deleting a old Windows installation? Its not something that you have to do that often and it's often a 20 minute google dredging to find any sort of information that is helpful.

I've had to do it twice in one week and refined a fairly easy way to accomplish the task in 3 commands.

First, open a Administrator level command prompt (Start -> "cmd", right click, Run as Administrator)

Next take ownership and RESET any ACL permissions on the files / directories:

takeown  /F "directory_path" /R /D y
icacls "directory_path" /reset /T

Now you can delete the files from explorer if you like or just do it from the same command prompt:

del /F /S/ Q "directory_path"

Problem solved! You can stop reading here if you don't care why those commands work.

So if you've made it this far, chances are you have found other instructions like this, but they tell you to run the icacls program with some sort of "/grant administrators:F switch" and the delete STILL DOESN'T WORK. Normally, that switch works splendidly. It doesn't work when adobe flash has been installed in the previous OS. For some reason, Adobe saw fit to mark their files as explicitly denying write access to "Everyone". Turns out this overrides other ACL permissions, so you have to clear it somehow. I chose to reset the ACL list, which then allows the current user to have write access with an appropriate UAC elevation!

Handy script for batch SVN inserts

Recently we came across a problem that required us to move our Subversion repository to a certain revision in the future (don't ask). As the revision number we needed to get to was a ways away from what we were currently at, I set up a handy dandy batch script to take care of the tedious task.

Set Count=0
:Rerun
REM Sets a new property on the trunk folder instead of actually modifying any files.
svn propset temp "AutoRev %Count%" Trunk
svn commit -m "Automatic Revision %Count%"
Set /A Count+=1
if %Count% lss 100 goto :Rerun

Enjoy!

Kiosk (Full Screen) WPF Applications

It seems that the WPF framework is somewhat fickle when it comes to window sizing in XAML vs Code. For example, the common advice for setting an application to fullscreen in in WPF applications is to set the WindowStyle=None and the WindowState=Maximized. When defined in XAML, this works great. When defined in code, it maximizes the window to the size of the working area on the screen. On my Windows Vista machine, the working area does NOT include the taskbar, thus making the application not a true fullscreen.

In my opinion, this aspect of WPF is very suspsect. Not only do the same properties work differently based on where you define them, but the order of other window operations is important (if you set the ResizeMode=NoResize after you set WindowMode=Maximized, the window clips off the screen).

Indeed it seems that the development team feels the same way and according to this post will be addressing the issue at some point in the future.After searching around, I've found that many solutions are offered up, but they all seem to be over complicated, or just not work at all. So, using an almalgamation of the cumulative sum of internet knowledge, I've made my own implementation. 

Below follows a simple extension class that can be called on a Window class that will kick the window into a fullscreen mode programatically.

 public static class FullScreenHelper
{
  public static void GoFullscreen(this Window window)
  {
      // Make window borderless
      window.WindowStyle = WindowStyle.None;
      window.ResizeMode = ResizeMode.NoResize;

      // Get handle for nearest monitor to this window
      WindowInteropHelper wih = new WindowInteropHelper(window);
      IntPtr hMonitor = MonitorFromWindow(wih.Handle, MONITOR_DEFAULTTONEAREST);

      // Get monitor info
      MONITORINFOEX monitorInfo = new MONITORINFOEX();
      monitorInfo.cbSize = Marshal.SizeOf(monitorInfo);
      GetMonitorInfo(new HandleRef(window, hMonitor), monitorInfo);

      // Create working area dimensions, converted to DPI-independent values
      HwndSource source = HwndSource.FromHwnd(wih.Handle);
      if (source == null) return; // Should never be null
      if (source.CompositionTarget == null) return; // Should never be null
      Matrix matrix = source.CompositionTarget.TransformFromDevice;
      RECT workingArea = monitorInfo.rcMonitor;
      Point dpiIndependentSize =
          matrix.Transform(
          new Point(
              workingArea.Right - workingArea.Left,
              workingArea.Bottom - workingArea.Top));

      // Maximize the window to the device-independent working area ie
      // the area without the taskbar.
      // NOTE - window state must be set to Maximized as this adds certain
      // maximized behaviors eg you can't move a window while it is maximized,
      // such as by calling Window.DragMove
      window.MaxWidth = dpiIndependentSize.X;
      window.MaxHeight = dpiIndependentSize.Y;
      window.WindowState = WindowState.Maximized;
  }

  // Nearest monitor to window
  const int MONITOR_DEFAULTTONEAREST = 2;

  // To get a handle to the specified monitor
  [DllImport("user32.dll")]
  static extern IntPtr MonitorFromWindow(IntPtr hwnd, int dwFlags);

  // To get the working area of the specified monitor
  [DllImport("user32.dll")]
  public static extern bool GetMonitorInfo(HandleRef hmonitor, [In, Out] MONITORINFOEX monitorInfo);

  // Rectangle (used by MONITORINFOEX)
  [StructLayout(LayoutKind.Sequential)]
  public struct RECT
  {
      public int Left;
      public int Top;
      public int Right;
      public int Bottom;
  }

  // Monitor information (used by GetMonitorInfo())
  [StructLayout(LayoutKind.Sequential)]
  public class MONITORINFOEX
  {
      public int cbSize;
      public RECT rcMonitor; // Total area
      public RECT rcWork; // Working area
      public int dwFlags;
      [MarshalAs(UnmanagedType.ByValArray, SizeConst = 0x20)]
      public char[] szDevice;
  }
}

Miracle fix for slow computers

This week I discovered an absolutely amazing fix an issue that had been wreaking havok on my computer for a while. 

The Problem?

Normal operation appeared always appeared fine. The problem came about as soon as any application that stressed the system was ran. The fans would spin up and the machine would run fine for a few minutes, then suddenly start crawling. When this happened, I would have absolutely terrible preformance for about 3 minutes, then suddenly, everything would go back to normal until the next burst. Eventually, the intervals shrank until I was always in terrible preformance land and ended up gave up whatever it was I was doing in frustration. 

Using ProcessExplorer I was able to see that the system was spending about 50% of the CPU time in an application called audiodg.exe and the rest in Kernel operations. After a little reasearch, I found that process is the Audio Device Graph host for the Vista sound stack. Basically a muxing point for your audio sources to your audio outputs. 

From there, A completely baseless assumption that Creative Is Evil caused me to immeditally place the blame on the Creative Audigy sound card drivers. I went into the control panel and disabled the sound card. Instant improvement. Things weren't perfect, but audiodg.exe never spiked and the preformance was tolerable.

Finally I got sick of not having sound and decided to plug in a old SoundBlasterLive! card I had. Bam, same problem, different drivers.

In my efforts to retreive some of the preformance that I lost, I started venturing into the world of video card tweaking.  After installing RivaTuner, imagine my suprise when I saw the core tempature of my GPU at over 100°C and CPU at 90°C. 

The fix? 

Blow out the dust. 

Upon opening the case, I found the CPU caked with dust. The video card had a dust bunny colony formed deep in a heat sink that required I remove plate in order to get to. After cleaning everything up, preformance is way up and tempatures are way down. My wife also noticed that the 'computer doesn't sound like its going to take off anymore'. 

Interestingly enough, the laptop that I use for work started having similar problems. Any sort of load would gradually bring the system to its knees which the CPU spending a majority of its time in kernel operations. The same fix worked for the laptop, although all I had to do with that was hit the exhaust port with a compressed air.