Tag Archives: Windows 10

While packaging a few Intel drivers (video driver, USB 3.0, chipset, management engine components, etc.) for our HP laptops, I noticed that each of the driver downloads contained a file named “mup.xml”. This file contains, among other things, information about valid command line switches for the setup.exe installer.

A snippet of the mup.xml file for our video driver is below. Some valid command line switches (which I haven’t fully tested) that appear within the file are:

/v = extract drivers (providing a double-quote encapsulated path is optional)
/s = unattended (silent install)
/? = help
/overwrite = force (install over previous installation)
/report = change the log file location from the default (C:\Intel) by providing double-quote encapsulated path

It seems that using a dash/hyphen in place of the forward slash is also acceptable. Ex.: /silent or -silent are both valid.

The mup.xml file also contains information on non-zero exit codes that may be returned by the installer. So far, I’ve encountered exit code 14, REBOOT_REQUIRED, a few times.

    <behavior name="freshinstall">
        <optionvalue switch="/" requiresvalue="false">s</optionvalue>
    <!--Driver Only Package, Installer Doesn't need to support
    <behavior name="driveronly">
         <optionvalue switch="/" requiresvalue="false"></optionvalue>
      <behavior name="applicationonly">
         <optionvalue switch="/" requiresvalue="false"></optionvalue>
    <behavior name="extractdrivers">
          <containervalue switch="/" requiresvalue="false" valuedelimiter=" " enclose="&quot;">v</containervalue>
          <optionvalue switch="" requiresvalue="true" valuedelimiter="=" enclose="\&quot;">ExtractDrivers</optionvalue>
    <behavior name="attended" />
    <behavior name="help">
        <optionvalue switch="/" requiresvalue="false">?</optionvalue>
    <behavior name="unattended">
        <optionvalue switch="/" requiresvalue="false">s</optionvalue>
      <!-- The DUP will Restart the system
        <optionvalue switch="/" requiresvalue="false">b</optionvalue>
    <parametermapping name="force">
        <optionvalue switch="/" requiresvalue="false">overwrite</optionvalue>
    <parametermapping name="logfile">
        <optionvalue switch="/" requiresvalue="true" valuedelimiter=" " enclose="&quot;">report</optionvalue>
    <returncodemapping name="REBOOTING_SYSTEM">
    <returncodemapping name="PASSWORD_REQUIRED">
    <returncodemapping name="NO_DOWNGRADE">
      <!--Always able to DownGrade, Installer Doesn't need to support-->
    <returncodemapping name="REBOOT_UPDATE_PENDING">
      <!--Installer only Reboots Once, Installer Doesn't need to support-->
    <returncodemapping name="DEP_SOFT_ERROR">
    <returncodemapping name="DEP_HARD_ERROR">
    <returncodemapping name="SUCCESS">
    <returncodemapping name="ERROR">
    <returncodemapping name="REBOOT_REQUIRED">
    <returncodemapping name="ERROR_INSTALL_PLATFORM_UNSUPPORTED">
    <returncodemapping name="UNKNOWN_OPTION">
    <returncodemapping name="ERROR">
    <returncodemapping name="ERROR">
    <returncodemapping name="ERROR">

So far, I’ve had good luck with the command: setup.exe /s /overwrite.

I have found error ID 40, with the description “The event logging service encountered an error when attempting to apply one or more policy settings.” is written to the System event log when the Group Policy setting “Specify the maximum log file size (KB)” under “Windows Components/Event Log Service/System” is configured (either enabled and set to a valid size or disabled).

Log Name:      System
Source:        Microsoft-Windows-Eventlog
Date:          2/18/2016 11:44:46 AM
Event ID:      40
Task Category: None
Level:         Error
Keywords:      Service availability
User:          LOCAL SERVICE
Computer:      mycomputer.mydomain.com
The event logging service encountered an error when attempting to apply one or more policy settings.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <Provider Name="Microsoft-Windows-Eventlog" Guid="{FC65DDD8-D6EF-4962-83D5-6E5CFE9CE148}" />
    <TimeCreated SystemTime="2016-02-18T17:44:46.789855700Z" />
    <Correlation />
    <Execution ProcessID="1140" ThreadID="5600" />
    <Security UserID="S-1-5-19" />
    <ChannelPolicyApplicationError xmlns="http://manifests.microsoft.com/win/2004/08/windows/eventlog">
      <Error Code="5">

The same error will appear when the Group Policy setting “Specify the maximum log file size (KB)” is configured under “Windows Components/Event Log Service/Application” or “Windows Components/Event Log Service/Security”.

Unfortunately, the SCM Windows 10 TH2 – Computer GPO (which I like to use as a baseline security GPO) sets the maximum log size for the Application, Security and System logs, and because disabling the setting in a GPO with a lower link order does not prevent the errors from appearing, I have to choose between changing the Microsoft security baseline GPO and living with the errors in the event log. I have decided to modify the GPO and set the three maximum log size settings to Not Configured, and then change the size of the System event log using the command “wevtutil sl System /ms:33554432”, the Application event log with “wevtutil sl Application /ms:33554432” and the Security event log with “wevtutil sl Security /ms:201326592” during the SCCM OSD task sequence.

The outcome is that the logs are configured to their recommended sizes, as specified in the SCM GPO, but GP is not enforcing the log size. I feel like this is an acceptable workaround, as it avoid the errors in the System event logs, sets the logs to the Microsoft-recommended size, and standard users will not be able to change the maximum log size via the Log Properties page.

I have been working on some unattended installation scripts for applications to be deployed through an SCCM OSD task sequence that builds our Windows 10 workstations. Happily, many of the lessons learned with Windows 7 are directly applicable to Windows 10. However, Windows 10 has made a significant change to the way applications are able to set themselves as the default application for handling certain file types.

Recently, I’ve been working on migrating our Adobe Acrobat XI package from Windows 7 to Windows 10. Among the first things we noticed was that in Windows 10, Microsoft Edge remained the default handler for the .PDF file extension, even though we had configured Acrobat to be the default handler through the Adobe Customization Wizard. This discovery led to much investigation about the changes in Windows 10 that are purportedly intended to protect a user’s choice of applications. I’m not altogether sold on this as a way of protecting user choice, as it seems more like it’s trying to force users into using the application of Microsoft’s choice rather than the one the user has installed.

A good technical explanation of the changes to the registry employed by Windows 8 and later to protect certain file extensions can be found in this post: http://appsensebigot.blogspot.co.uk/2015/10/deploying-per-user-file-type.html. To quickly summarize, since Windows 7, Microsoft has added a new registry subkey, named “UserChoice”, to certain file extensions under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts, and the contents of the UserChoice subkey dictate the default application for opening the file type. The contents of the UserChoice subkey are protected from modification by a Deny permission applied to the current user’s account. Unfortunately, the workaround for Windows 8/Server 2012 R2 described in the post does not seem to work in Windows 10.

Let’s use Regedit to look at the registry entries for the .PDF file extension at HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf. Out of the box, Windows 10 will set the contents of the UserChoice subkey to have the Progid value point to Microsoft Edge, referenced by its Windows application ID. The Hash value will contain a data that seems to be generated from the current user’s username, the computer name and the application, meaning that it will be unique for each user/computer/application combination. Thus, it would be difficult, and foolish, to try to calculate that value ourselves. You’ll also notice that you cannot change the data of the Progid or Hash values through Regedit. If you right-click the .pdf key and choose Permissions, you’ll see that the current user has special permissions assigned. Clicking on the Advanced button will show you that the current user is prevented from setting values under the UserChoice key by way of a Deny permission entry.

All of this makes things look pretty bleak.

But Microsoft has not forgotten about us system administrators. They have provided a way forward!

The best description I’ve found of Microsoft’s horrible, short-sighted method for system administrators to get around the UserChoice keys and set default application file associations can be found at this TechNet blog post: http://blogs.technet.com/b/mrmlcgn/archive/2013/02/26/windows-8-associate-a-file-type-or-protocol-with-a-specific-app-using-a-gpo-e-g-default-mail-client-for-mailto-protocol.aspx. There are many reasons why this method is unusable, but a very obvious one is that it isn’t graceful for deploying different combinations of default applications to different users. It’s completely unwieldy for configuring a multi-user XenApp server where users may have different default applications for the same file extension. It’s also clunky when it comes time to deploy a new version of an application that has been previously configured, as we would need to know which other extensions have been configured for that computer in the past before we change the handler to new application. Read the comments if you are curious about how your fellow sysadmins feel about this method.

A better method would avoid these problems and enable us to configure default applications per-user. So let’s engineer something.

The first thing we need to do is somehow deal with that UserChoice key. While we are not able to change the values under the key, the permissions allow us to delete the UserChoice key itself, with a catch. The catch is that we can’t use a simple REG DELETE command to delete the UserChoice key as it returns an “ERROR: Access is denied.” response. Trying REG DELETE against the parent subkey, .pdf, will delete everything except for the UserChoice key. Watching this process with Sysinternals Process Monitor shows that reg.exe tries to open the UserChoice key while requesting “All access”, which it won’t receive. But we can use REG IMPORT to import a .REG file that deletes the key. So far, it appears that deleting the key one time prevents it from returning at subsequent logons, so long as you have a local Windows profile to log on to. If you are using a mandatory profile, I expect that the key will be created at each logon and you’ll need to delete it at each logon.

I have found that when the UserChoice key is absent, the settings under the file type key are honored.

Once we’ve dealt with that UserChoice key, setting the remaining registry values under the extension key that configure the default application is straight-forward and familiar.

An example of the registry method for Adobe Acrobat Pro DC

By way of example, below is a .REG file that I am using to configure Adobe Acrobat Pro DC (also known as Acrobat 2015) as the default application for .PDF files. This file will delete the entire .pdf subkey to get rid of the UserChoice key and any other values that would set Microsoft Edge to be the default handler and then configure the values under the OpenWithList and OpenWithProgids keys to make Acrobat Pro DC the default handler.

Windows Registry Editor Version 5.00

;Delete the .pdf key under FileExts to clear the Microsoft Edge application association (which is the default handler for .pdf) and the UserChoice subkey.

;Configure the .pdf key under FileExts to set Acrobat as the default handler.



One way of deploying these settings would be to drop this .REG file onto the computer or a share on your network, then create a GPP Registry item, set to “Apply once and do not reapply”, that creates a value under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce to launch the command C:\Windows\System32\reg.exe IMPORT <path-to-REG-file>. At the user’s next logon, the RunOnce key will cause reg.exe to import the .REG file that deletes the UserChoice key and configures the default application. A nice advantage to using using the GPP Registry item is that it can be item-level targeted to a situation, for example, to an AD security group of users or to users logged onto computers with a certain application installed.

In my experience, the end result is that the user sees the correct Adobe Acrobat icon for .PDF files and double-clicking a .PDF file launches it in Adobe Acrobat without any prompting to set Acrobat as the default application for opening PDFs.

Over the Thanksgiving weekend, I upgraded one of my computers from Windows 7 to Windows 10 using Windows Update. It had been nagging me to upgrade for awhile and I finally gave in and did it. The upgrade appeared to go smoothly, but when I logged on to Windows 10 for the first time, I realized that I didn’t have any of my settings or files. I checked the Application event log and sure enough, I was logged in with a TEMP profile.

I Googled this a bit, thinking that perhaps it has happened to a few other people who could point me to a quick resolution, but it didn’t seem to be a common problem. Also, the proposed fixes (like running sfc /scannow didn’t strike me as being very promising.

So I open the Local Users and Groups manager (lusrmgr.msc) and checked the group membership of my account. I found that it was a member of the Administrators group and a HomeUsers group, but not a member of the Users group. I checked a Windows 10 computer that I had built from the 10240 build ISO as a clean install and didn’t find a HomeUsers group at all. Back on the problem computer, I added my broken account to the Users group, restarted, and logged in. This time, Windows took my account through the typical first-run setup stuff and then loaded the correct profile, with all of my settings and files from Windows 7 intact.

So, if you run into the problem where an account on a recently upgraded Windows 10 computer is missing settings and files, check the group membership. If the account is not a member of the Users group, you will not be able to log in properly. Add the account to that group, logout and then log back in. Your problem should be fixed

Today I learned that Microsoft Edge on Windows 10 does work with an Enterprise Mode Site List after all. I had been trying in vain for weeks (off and on) to get it to redirect into Internet Explorer those sites that I had configured to do so through the Enterprise Mode Site List XML file. As far as I could tell, I was correctly using the Group Policy setting “Allows you to configure the Enterprise Site list”, providing a valid UNC path to the sites.xml file on our DFS. No matter how I configured the contents of the file, Edge simply would not perform the redirection. The redirection would work flawlessly if I configured the Group Policy setting “Sends all intranet traffic over to Internet Explorer”, but I didn’t want to open all of our intranet sites in IE, and there were plenty of Internet sites that I wanted to open in IE.

Internet Explorer 11 on Windows 7 had been successfully retrieving the sites.xml file via a UNC path, rather than an URL, for months. Furthermore, Internet Explorer 11 on Windows 10 was able to retrieve the file via UNC path. Running short of new things to try, on a whim, I copied the sites.xml file to a web server and provided the path in the Group Policy setting as an HTTP address, and lo and behold, Edge happily loaded the file and redirected users to Internet Explorer.

To be sure I wasn’t making up the ability to use a UNC path, I checked the TechNet article Use Enterprise Mode to improve compatibility, which is part of the Microsoft Edge – Deployment Guide for IT Pros. It clearly states that the SiteList value at HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\MicrosoftEdge\Main\EnterpriseMode accepts a UNC path, and this is what was being created by my Group Policy setting. However, the Group Policy setting’s field, into which you enter the path, asks for a URL. So, perhaps the TechNet document is wrong. Maybe the editor simply copied and pasted from the IE11 article Turn on Enterprise Mode and use a site list, and did not validate those instructions for Microsoft Edge.

Anyway, I hope that this post helps other systems administrators who may find themselves in the same situation, but I also wish that Microsoft would address this inconsistency between Edge and IE. A UNC path on our DFS (which is something within my control) is far easier for me to administer than a file on a web server (which is outside of my control).

This Windows Event Viewer query looks through the Network Profile/Operational log for network connection events (EventID=10000) where the “Category” equals “2”, which equates to “Domain Authenticated”. The neat part about this XML query is that it looks into the event details for additional criteria, which isn’t available through the filter GUI.

  <Query Id="0" Path="Microsoft-Windows-NetworkProfile/Operational">
    <Select Path="Microsoft-Windows-NetworkProfile/Operational">*[System[(EventID=10000)]] and *[EventData[Data[@Name='Category'] and (Data='2')]]</Select>

I use it as the custom query trigger for a scheduled task that initiates a few actions each time the computer is powered on/woken up while on the domain network, or has its network connection reestablished. A similar query without the Category=2 criteria would be triggered twice each time the computer is powered on: once when the network connection is established but on the public firewall profile (or something like that), and a second time when the connection changes to use the domain firewall profile (again, I’m not exactly clear).

For a good explanation of how to construct custom queries with examples, see the TechNet blog post at Advanced XML filtering in the Windows Event Viewer.

Update 8/12/2015: I’ve determined that the problem is due to my attempts at creating a custom Windows.UI.Logon.pri file to display a logon screen background image. Neither the utility nor the PowerShell script referenced below create a Windows.UI.Logon.pri file that is acceptable to Windows. In the meantime, I’ve decided to just eliminate the “Hero” wallpaper in favor of a solid color.

I’ve encountered a problem with Windows 10 Enterprise with Cumulative Update for Windows 10: August 5, 2015 (KB3081424) applied, where the secure logon screen is completely black instead of displaying the Ctrl+Alt+Delete message, clock, background wallpaper, etc.

Prior to KB3081424, I experienced a different problem at the Ctrl+Alt+Delete screen, where the lock screen wallpaper configured via Group Policy was not applied and the background was instead a solid blue color.

In both cases, the behavior was/is only evident when the registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableCAD is set to 0 (enforcing the Ctrl+Alt+Del screen). Deleting the DisableCAD value avoids the problem, however, it also removes the benefit of the secure logon screen.

When the computer is locked (for example, by hitting Ctrl+Alt+Del and selecting the Lock option) and the screen goes black, the following event is written to the Application event log:

Log Name:      Application
Source:        Application Error
Date:          8/7/2015 5:06:41 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      mycomputer.mydomain.com
Faulting application name: LogonUI.exe, version: 10.0.10240.16384, time stamp: 0x559f398c
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.10240.16412, time stamp: 0x55b9a054
Exception code: 0xc000027b
Fault offset: 0x0000000000494ab9
Faulting process id: 0x1fdc
Faulting application start time: 0x01d0d15d56f2c0bf
Faulting application path: C:\WINDOWS\system32\LogonUI.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: 351d24a4-a031-4135-b595-334baef2ba99
Faulting package full name: 
Faulting package-relative application ID: 

Watching the LogonUI.exe process with Sysinternals Procmon shows that the process crashes when the computer is locked, causing the screen to go black. Hitting the Ctrl+Alt+Del key combination at the black screen launches a new LogonUI.exe process, the wallpaper image loads, and I’m taken to the logon page where I can enter my username and password and log on.

The problem exists on physical hardware as well as in a VMware Workstation 11 virtual machine, so I’m confident that it is not a driver-related issue. The only other particular thing about my setup is that I’m generating my own Windows.UI.Logon.pri wallpaper file using the utility discussed at: http://www.askvg.com/how-to-change-or-disable-login-screen-background-image-in-windows-10/ (although revisiting this page now indicates that .pri file generated by the utility may be responsible for lock screen problems).

I’ll test with the default wallpaper image, and with my desired wallpaper image repacked using the PowerShell script at: http://pastebin.com/aMBrHRwd .

Even if the Windows.UI.Logon.pri is the cause of the LogonUI.exe crashes, a bad file seems like something that the LogonUI process should tolerate.

I posted the problem to Microsoft’s Windows Feedback on 8/10/2015. A Google search turned up a few other people who have had problems at the lock screen, and there are a number of reports of similar problems going back a few versions of Windows.