Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Why Aren’t My Windows Audit Policies Working?

Posted by William Diaz on January 31, 2014

So, recently I had the need to setup auditing on a local workstation to try and determine who or what was deleting a specific set of files. Before we started, we decided to test the auditing on a couple PCs to audit all failed and successful attempts to delete any files or folders within some random test folder. Audit events are recorded in the Security logs of the Windows Event Viewer. Specifically, Audit Object Access events of interest are event ID 4656 (A handle to an object was requested) and 4663 (An attempt was made to access an object). The details should allude to the responsible user account and process. But to our surprise our test folder was not recording any audit events for any of the objects inside.

Maybe an oversight but perhaps auditing was not enabled in group policy. But a quick check revealed that it was being set for both success and failure:


Maybe it wasn’t getting applied to the workstation. Although deprecated since Vista, RSOP from the command line is useful for quickly spotting polices that might not be getting applied to the local computer. Sure enough I could see there was a problem with the audit policies: “The policy engine did not attempt to configure the setting…


Read the rest of this entry »

Posted in Inside Windows | 1 Comment »

A Typo

Posted by William Diaz on January 30, 2014


Posted in Uncategorized | Leave a Comment »

The Case of the Ghost Files in IE

Posted by William Diaz on January 24, 2014

While in the process of composing an web-based email today via Internet Explorer, I noticed something odd when I went to attach a file to the message. In the IE file upload dialog there were a series of files listed on the desktop that I knew were not really there. Judging by the dates they had been hanging around for some time now but I had never noticed them (and, no, they were not hidden or marked as protected operating system files):


The files themselves were no mystery; they are nothing more than text files that dump process, thread, and stack information to the desktop when the JRE crashes. I tried to attach one of these to the web message but nothing would happen. However, from within in the dialog box I could right click and open them like any other files. Attempting to move the file also failed because the file itself apparently didn’t exist:


If that was the case, I should then get the same message trying to copy it back to the desktop. Instead, the dialog this time indicated it did exist:


I wondered if I could access these ghost files from outside IE by, for example, attaching them to a message in Outlook. Not surprisingly, the same set of files did not appear from the desktop location:


This was likely something specific to IE. To determine where the files were actually residing, I turned to Process Monitor, started a trace for file activity and proceeded to open one of the ghost files via the IE File upload dialog box. Afterwards, I stopped the trace and did a search for the file in question.


There was half the mystery, the files actually resided in C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\username\Desktop. The other half of the mystery was then just a matter of some quick research into IE and Virtualized folders. That lead me to this MSDN article Understanding and Working in Protected Mode Internet Explorer. In short:

A Compatibility Layer handles the needs of many existing extensions. It intercepts attempts to write to medium integrity resources, such as the Documents folder in the user profile and the HKEY_CURRENT_USER registry hive. However it will not intercept writes to system locations like Program Files and HKEY_LOCAL_MACHINE. The compatibility layer uses a Windows Compatibility Shim to automatically redirect these operations to the following low integrity locations:

  • Documents and Settings\%userprofile%\LocalSettings\TemporaryInternet Files\Virtualized (pre-Vista)

If I unchecked Enable Protected Mode in IE the virtual files no longer appeared in the file IE file dialog. Not that you don’t want to do that, just delete the files instead.

Posted in Troubleshooting | Tagged: | Leave a Comment »

“The User Profile Service service failed the logon”

Posted by William Diaz on January 14, 2014


Today, I encountered the following on a newly imaged workstation: “The user Profile Service service failed the logon. User profile cannot be loaded.”


Often times when I encounter this it’s a simple matter of hacking the registry to fix it. This is covered in detail in this Microsoft KB You receive a "The User Profile Service failed the logon” error message. It also covered in one of my older (pre-MS KB) blogs.

The article, however, doesn’t cover the other scenario. Local admin and domain techs accounts could logon but not standard users accounts. This is often due to file permissions. For whatever reason, a system-admin protected file was created deep into the profile of the Default user account. This is where all new profiles are created from, and Everyone\Users must have at least read permissions for a new profile to be successfully spawned from the Default. The details are alluded to in the Windows Application event logs, event ID 1509:

Windows cannot copy file \\?\C:\Users\Default\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm to location \\?\C:\Users\TEMP\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm. This error may be caused by network problems or insufficient security rights.

DETAIL – Access is denied.


Looking at the problem file, we can see that the file has no permissions for Everyone\Users:


The solution is to delete the file (if non-essential) or add the correct user(s) and permissions. And depending on the location, you may need to uncheck Hide protected operation system files in Windows Explorer.

Posted in Troubleshooting | Leave a Comment »

USB BitLocker Policy May Not Apply To Some Android Devices

Posted by William Diaz on November 21, 2013

During recent BitLocker piloting for USB mass storage devices we noticed that Android devices were not affected by our Bitlocker policy, which was to prevent writing of data if the device was not encrypted. Although we do not intend to enforce encryption on these devices for obvious reason, we still wanted to be able to deny write to the devices in the same manner that users could not write to their BlackBerry or iPhone devices where USB BitLocker policy was to deny write was working as expected.

After opening a case with Microsoft, the conclusion was that even though the Android devices were mass storage devices, they were presenting themselves as Windows Portable Devices:

>>  [Device Install (Hardware initiated) – WpdBusEnumRoot\UMB\2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_SMI&PROD_USB_DISK&REV_1100#7&2DEFC6D0&0#]
>>>  Section start 2013/11/12 14:30:18.871
     ump: Creating Install Process: DrvInst.exe 14:30:18.871
     ndv: Retrieving device info…
     ndv: Setting device parameters…
     ndv: Doing WU search last due to CM_DEVCAP_SILENTINSTALL flag.
     ndv: Searching Driver Store and Device Path…
     dvi: {Build Driver List} 14:30:18.949
     dvi:      Searching for compatible ID(s):
     dvi:           wpdbusenum\fs

     dvi:           DrvDate      – 06/21/2006
     dvi:           Version      – 6.1.7600.16385
     inf:      Searched 1 potential matches in published INF directory
     inf:      Searched 35 INFs in directory: ‘C:\Windows\inf’
     dvi: {Build Driver List – exit(0x00000000)} 14:30:19.074
     ndv: Selecting best match from Driver Store (including Device Path)…
     dvi: {DIF_SELECTBESTCOMPATDRV} 14:30:19.074
     dvi:      Using exported function ‘WpdClassInstaller’ in module ‘C:\WINDOWS\system32\wpd_ci.dll’.
     dvi:      Class installer == wpd_ci.dll,WpdClassInstaller
     dvi:      No CoInstallers found
     dvi:      Class installer: Enter 14:30:19.089
     dvi:      Class installer: Exit
     dvi:      Default installer: Enter 14:30:19.089


A normal USB mass storage device, e.g. a flash drive, otherwise presents itself in manner that USB BitLocker policy could be applied to because the device is recognized as mass storage:

>>>  [Device Install (Hardware initiated) – STORAGE\Volume\_??_USBSTOR#Disk&Ven_SMI&Prod_USB_DISK&Rev_1100#7&2defc6d0&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}]
>>>  Section start 2013/11/12 14:30:16.765
     ump: Creating Install Process: DrvInst.exe 14:30:16.796
     ndv: Retrieving device info…
     ndv: Setting device parameters…
     ndv: Doing WU search last due to CM_DEVCAP_SILENTINSTALL flag.
     ndv: Searching Driver Store and Device Path…
     dvi: {Build Driver List} 14:30:16.812
     dvi:      Searching for hardware ID(s):
     dvi:           storage\volume

dvi:           DrvDate      – 06/21/2006
     dvi:           Version      – 6.1.7601.17567
     inf:      Searched 1 potential matches in published INF directory
     inf:      Searched 35 INFs in directory: ‘C:\Windows\inf’
     dvi: {Build Driver List – exit(0x00000000)} 14:30:16.937
     ndv: Selecting best match from Driver Store (including Device Path)…
     dvi: {DIF_SELECTBESTCOMPATDRV} 14:30:16.937
     dvi:      Using exported function ‘VolumeClassInstaller’ in module ‘C:\WINDOWS\system32\SysClass.dll’.
     dvi:      Class installer == SysClass.dll,VolumeClassInstaller
     dvi:      Using exported function ‘CriticalDeviceCoInstaller’ in module ‘C:\WINDOWS\system32\SysClass.Dll’.
     dvi:      CoInstaller 1 == SysClass.Dll,CriticalDeviceCoInstaller

This information is written each time you connect a USB device to a Windows computer and can be found in C:\Windows\inf\

The workaround is to apply a Deny Write Access to WPD devices in Computer Configuration\Administrative Templates\System\Removable Storage Access.

Posted in Uncategorized | Leave a Comment »

Configure WinHttp for Proxy

Posted by William Diaz on November 3, 2013

Recently, we were testing a new remote desktop application but I was experiencing problems connecting to the application, and it wasn’t isolated to a single workstation. A few of my other labs were unable to access the application as were other computers as the testing expanded. Admittedly, I should have figured this one out quickly as it was not the first time I encountered an issue trying to access remote desktop applications (i.e. terminal server apps) inside our network. The fact that we were hosting this RDP app internally, though, lead me to dismiss my initial hunch. A quick look with Network Monitor confirmed the problem:


The Windows local security authority processes (lsass.exe) is trying to get out to the cloud to do something, in this case likely some certificate revocation checking (this is usually the case for RDP apps). It keeps on trying by retransmitting until a response is received or it times out, but because we are behind a proxy, lsass.exe will never find a path outside the network. Certificate checking is handled by the Windows crypto API, which relies on WinHttp. Now, by default, Winhttp 5.1 can find a way out of the network if your network is configured to use Web Proxy Autodiscovery (WPAD). We do not, so the fix is to manually configure Winhttp to use some proxy. Since we have this information configured in Internet Explorer (along with proxy exceptions), we just need to import these settings into Winhttp via (elevated command prompt) netsh winhttp import proxy source=ie. Afterwards, the connection problem resolved*.

On the flipside, configuring Winhttp to use a static proxy can also cause connectivity problems for mobile users. I ran into this issue myself today when I was trying to stream a movie from Netflix and kept on encountering the following error: “Whoops. something went wrong… An Internet or home connection network connection problem is preventing playbackError code: H7111-1101”


To verify my suspicion that the opposite was true—that Winhttp was trying to use a proxy it could not reach to do certificate verification checks—I looked in the Windows event CAPI2 logs and could see that the Netflix certificate check was failing:


The details pane further down revealed the cause as the certificate server was “offline”, which is just a generic term for can’t be found. You can verify your winhttp proxy via netsh winhttp show proxy. To correct, simply set the winhttp proxy to use direct connection via netsh winhttp reset proxy when outside the network.

*Certificate verification does not need to be performed for every session, i.e. the initial check is good enough until the crypto API determines that the information is expired and another check needs to be performed.

I am not sure why yet, but Netmon captures on a Windows 8.1 system did not reveal the lsass.exe process. Instead, the process was listed as unavailable.


Posted in Troubleshooting, Troubleshooting Tools | Tagged: , | Leave a Comment »

IE 11, Page can’t be displayed,, & SPDY/3 Protocol

Posted by William Diaz on October 28, 2013

I’ve been taking Internet Explorer 11 for a test drive recently and started to notice an odd occurrence. Upon initially opening IE 11 and typing into the address bar, I am unable to get to the page, instead getting the generic : “This page can’t be displayed…


A quick refresh, however, had no problems taking me to the page afterwards. Closing IE (and making sure all iexplore.exe processes are closed via the Task Manager) and typing the same URL again would reproduce the problem roughly 8 out of 10 times. A quick look with Network Monitor should that connection was, in fact, successful:


Looking at one of the frames in the network capture showed the presence of an additional HTTP protocol I wasn’t familiar with in Internet Explorer, SPDY/3:


I remember seeing it in the Advanced tab of the Internet Explorer settings:


Unchecking this setting resolved the issue. I am not sure why this is happening. SPDY/3 is a relatively new open protocol introduced by Google and being adapted by IE. More about it can be read here: & In short, it makes the browser speedier by reducing web page load times.


Seems to be reproducible only behind a proxy, TMG in our case.

Posted in Uncategorized | Tagged: , | 9 Comments »

Failed Java Uninstalls

Posted by William Diaz on October 23, 2013

After moving to Java 7 several months ago, this issue started plaguing us. During normal troubleshooting of Java applet-website issues techs would try to uninstall our custom Java 7 package, only to encounter: “There was a problem starting C:\Program Files (x86)\Java\jre7\bin\\installer.dll. The specified module could not be found.”


Up until recently, the fix was to run the Microsoft FixIt Utility to Fix problems with Programs that can’t be installed or uninstalled. Afterwards, we would then need to remove the stubborn registry entries that left the Program and Features application list populated with the now removed application by running the uninstall again. With the recent expiration of Java 7 update 25 and confusion from tier 1 support, there were several updates being done to the new JRE. In order to maintain a consistent software environment, I asked to have those updated JREs put back to 7.25. This also required uninstalling 7.25 on so many workstations that my head was left spinning because the process had to be done manually and I was the “go-to” person for the Java crisis. More importantly, at some point we would need to eventually update to a new JRE and likely want to remove the old one but not have a way to automatically uninstall the previous client with the uninstall broken.

After some web research, I found that the issue was with one of the custom actions in the Java msi, UninstallJRE:


This should be changed to:


Thanks to Keith Jones. Found this gem here:

Posted in Uncategorized | Tagged: | 3 Comments »

Um, So We’ll Have to Lower Java Security Again?

Posted by William Diaz on October 21, 2013

So, last week with the expiration of Java 7 Update 25, Java LiveConnect stopped working on several web sites that our users frequent, forcing them to change the default Java security setting from High to Medium. For arguments sake you could update to Java 7 Update 45 and go back to using the High security setting. But then I saw some additional text on one of the common Java 7 security dialogs: “This application will be blocked in a future Java security update because the JAR file manifest does not contain the Permissions attribute…”


Assuming the applet is not updated by the next JRE expiration, user’s would then have to lower Java security again.


Posted in Uncategorized | Tagged: | Leave a Comment »

Java Headaches After Update Release

Posted by William Diaz on October 17, 2013

So Java just released JRE 7 Update 45. This is apparent when someone goes to run a Java applet and encounters the following prompt:”Your Java version is out of date…”


For the average home user, this is not a big deal. But in a corporate environment headaches ensue. Why? Because some users will blindly click on the Update button and be redirected to the Java download page for the latest release. The first problem is that our users are not going to have the administrative privileges to update their Java client. But the real problem is that once a user has done this, they will be redirected to the Java download page each and every time they need to run a Java applet. So the question was, how do we get the prompt back so the user can select the appropriate Later option and Do not ask again until the next update is available?

For starters, the property that controls this setting is located in a file called in %userprofile\AppData\LocalLow\Sun\Java\Deployment named deployment.expiration.decision.10.25.2=update:

Posted in Troubleshooting | Tagged: | Leave a Comment »