Blog: Windows

I recently worked with a customer because their C: drive was out of space. He had another drive in their laptop (D: drive) that had 500GB of free space.  I decided to move all offline files from the C: drive to the D: drive. I found the following article and worked through it:

After getting the offline files synced, I started working to clean up the old location of the offline files. I took ownership and I was able to delete most of them, but I kept getting an error that I could not delete some of the files because “the file name was too long”. I spent a long time researching and trying to figure out how to gain this space back by deleting the files. I eventually created a share to the folder, accessed it from another system, and I was able to successfully delete it from there.




For some versions of the TPM chip found in the Lenovo ThinkPad T420, you will receive an Access Denied error message when attempting to encrypt the hard disk if you have a group policy enabled that restricts CD/DVD access.  Apparently, some models of TPM chip are seen by the system as a CD/DVD device, and will not function correctly if it has been disabled via Group Policy. 

The fix is to just disable the group policy until after the disk has been encrypted and the PIN has been setup.  Once it has been encrypted you can reapply the Group Policy and it will continue to function normally.



I have run into this issue recently with updates on several Windows 7 embedded thin clients.  The error code translates to a corruption in the Windows component store.

Running "sfc /scannow" on the systems indicated that it did find errors, but could not fix them.

The System Update Readiness tool (KB947821) was successful in repairing component store problems in all cases for me.  The download link is

After installing the patch, running Windows Update again to install patches was successful.


There has been a lot of discussion about whether a BitLocker pre-boot PIN increases security or not. The primary argument we have had is related to the PIN providing a layer of security between an attacker with physical access and the Windows credentials.

If a user is running Windows 8 or later and has encrypted the OS volume, there is a GPO designed to protect against Windows password guessing. If Windows credentials are cached, which is common for laptops, it is possible to bypass account lockout settings if the system doesn't have access to a domain controller. However, this GPO will help protect a system even if it can't reach a domain controller.

Administrators can set the “Interactive logon: Machine account lockout threshold” Group Policy under \Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.

When applied, this setting will cause the following message to be displayed shortly before the machine account threshold is reached. After the threshold is exceeded, the system will reboot and require a BitLocker recovery key in order to boot.


We have a backup internet connection that is tied into our Test Lab environment. As a part of this, I needed to change the default gateway on all of my Test Lab VMs so that everything would go out the proper connection. Now, I could RDP into each one and make the change, but that is boring and this is a LAB! It’s time to play a little bit and see if we can change this efficiently.

My initial thought was to use a combination of "psexec" and "netsh" commands to change that IP. I figured out the netsh command necessary to change an IP address (including the default gateway) and just left the IP address information out of the command. Much to my surprise, it set the adapter to DHCP, yet statically configured a default gateway. For our LAB this doesn't work since DHCP doesn't grab an address, but at least now I know. So how do you go about scripting a change to the default gateway for multiple Windows systems?

Use a route add command, of course! Using psexec to push the command out, I ran “route add -p mask” where is my new default gateway. Much to my surprise, it changed the default gateway entry on the adapter without issue.


I was recently working on a PowerShell Script that used Excel COM objects to pull data from remote computers put it into a spreadsheet. I finished up the script and tested it under my own account and got the result I was looking for—the data was pulled from the remote computers, an Excel spreadsheet was created and saved to a network share, and an email was sent out with the spreadsheet as an attachment.

Pleased with the script, I set it up as a Scheduled Task and set it to run under the credentials of an existing service account. When I manually ran the scheduled task, however, the script would not run. I tried using my own account for the scheduled task and it still would not run. I was using some formatting in Excel that would have been lost if I went with a CSV file and having to remember to manually run the task at the scheduled interval while I was logged in would not have been the best solution, so I decided to look for a solution rather than re-write the code.
After some digging, I discovered PowerShell scripts that use Excel COM objects—and presumably other COM objects—that run while a user is not logged in require the SystemProfile have a Desktop folder in order to run as scheduled tasks. The folder, however, does not exist under the C:\Users directory as you might expect. Instead, it is located at:
The empty “Desktop” directory itself needs to be created and nothing more—no special permissions or registry hacks. In the case of a 32-bit OS, only the first directory needs to be created. In the case of a 64-bit OS, *both* directories need to be created. In my case, I was on a 64-bit OS and the directory in System32 existed but the directory in SysWOW64 did not. Once I created the missing directory I was able to use the original service account to successfully run the scheduled task whether or not it was logged in to the system.


I was helping out with a customer’s Active Directory migration and a different IT support group used a profile migration tool to help “ease” the transition between domains. But soon after the users started complaining that IE was not allowing them to save passwords. They would get prompted to store the credentials for a website and click yes, but as soon as they closed and reopened IE their stored credentials would disappear. Our suspicion was that the profile migration tool had corrupted the credential store in the registry.

I started a remote session with one of the users, checked the IE password store in the registry (HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2), and saw several of the user’s old entries. In order to allow the user to store passwords again, I had to delete this registry key, reopen IE, and save credentials for a website. Once I clicked “yes” to the prompt to save credentials, the registry key was automatically recreated and the credentials got stored.


For several months, I dealt with the occasional task of having to restart my laptop (Windows 8.1) because the memory usage would get close to 100%, even with no apps running. There were no processes in Task Manager indicating high memory usage, so I suspected I had a memory leak in a faulty driver.
I first ran rammap.exe from Microsoft Sysinternals ( This tool showed that the non-paged pool memory usage was very high. But this didn’t tell me what process was causing the leak.

Next I downloaded and installed the Windows Driver Kit 10 from Microsoft ( This kit supports Windows 7 through Windows 10. I had to reboot to complete the install then wait until my system was running low on memory before continuing my diagnosis. Once I noticed I was low on memory again, I ran "poolmon –b –p" from C:\Program Files (x86)\Windows Kits\10\Tools\x64. The –p switch enables using Non-paged and Paged pool memory  and the –b switch sorts descending by bytes. At the top of my list was the tag "AVDT".

So how do you figure out what the tag is referring to? I opened an admin command prompt and entered "findstr /s AVDT *.sys". This searched all *.sys files (most driver files are *.sys) in all subdirectories (/s) on the C: drive for the string "AVDT". This returned a screen full of mostly non-readable text which was the contents of *.sys files containing the string "AVDT". It was fairly easy to see a path "\Program Files\WIDCOMM\Bluetooth Software\bin\btwavdt.sys". Looking at the properties of the file indicated what was obvious from the path, it was related to Bluetooth.
Whenever I would connect my iPhone via Bluetooth to my laptop and play music (in order to use my external speakers), the driver would eat up non-paged pool memory to the "tune" of 1 MB every 5 seconds! By opening Task Manager and viewing Memory on the Performance tab, I could literally watch the consumption of non-paged pool memory increase with every measure. Just having the phone connected via Bluetooth didn’t cause this, only when music was playing. At a rate of 1 MB every 5 seconds, it consumed about 2.8 GB of memory to listen to music for half of the day!
I searched to find a solution to this bug but did not not find one. So until I can get an updated driver, I won’t listen to music from my phone on my PC via Bluetooth. Or if I do, I know I only have a few hours before a reboot is needed.


I was using a scanning tool to scan some servers and workstations.  I could pull some information from the scan, but it would fail when attempting to collect information via Remote Registry.  After checking that the Remote Registry service was started and the firewall was not enabled, I attempted to connect to one of the systems remotely using regedit instead of the scanning tool.  The connection would appear to succeed, but as soon as I attempted to click on an entry, I would get an error message “Cannot open HKEY_LOCAL_MACHINE: Error while opening key.”  [more]After doing some research, I found this TechNet article (  It explains that systems that were upgraded from Windows 2000 may experience this issue because Windows 2000 ran Remote Registry under the “Local System” account, while XP/Server 2003 runs it under the “Local Service” account.  Once you give “Local Service” read access to a specific registry subkey on the target system, Remote Registry works.


Download link:

What is PsExec?  "PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec's most powerful uses include launching interactive command-prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems." [more]

I needed to reset some WSUS IDs on systems that were cloned in order to get them to check in to WSUS properly.   I used psexec to run commands as though I were typing them into the PC locally to start/stop services, delete a registry key, and check for updates from WSUS Server in the following example.

psexec \\remotePC net stop wuauserv
psexec \\remotePC REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
psexec \\remotePC net start wuauserv
psexec \\remotePC wuauclt /detectnow

You can also use this to run ipconfig and it will show you the results from the REMOTE system which could come in handy.