Category: Windows 10

Starting with Windows 10 Fall Creators Update Microsoft has revamped the OneDrive client and is now offering On-Demand synchronization of files. For those of you that remember we had the similar behavior in Windows 8.1 but this was changed for Windows 10.

There is a huge difference though in how OneDrive On-demand sync works in comparison to how it has been working in Windows 8 and 10 previously. OneDrive is now not just a part of the shell in Windows, it has integration with file system drivers from the kernel. This basically means that we do not face any compatibility issues with applications working with files in OneDrive as there is native Win32 support for accessing files in OneDrive.

So, with OneDrive On-Demand sync you have three states of the files (more about OneDrive On-Demand sync at the Windows blog). The Icons below marks that the files are downloaded and located on the machine.

Now, let’s look in the good old command prompt using the dir command to see the status of the above files. Nothing special with this, right?

But hey, the command attrib has been updated to adhere to the new features of OneDrive On-demand sync.

To pin a file (i.e. make it always available offline) use the command:

attrib +p -u Document2.docx

To unpin a file (i.e. make it available only in the cloud) use the command:

attrib -p +u Document1.docx

So, the end result in Windows File Explorer is as below. The cloud icon indicate that the file is only available in the cloud. The green circle with checkmark indicates that the file is always available offline.

Followed by this view in dir, i.e. note the parenthesis around the file which is available online only.

Pinning and unpinning multiple files and folders

To pin or unpin multiple files or folders, use the /s switch. To make all files and folders available recursively:

attrib +p -u /s

and to make all files and folders available in the cloud only:

attrib -p +u /s

Summary

To summarize with this new approach and the introduction of OneDrive On-demand sync you will have full application compatibility with OneDrive as well as the possibilities to aid users in controlling their OneDrive files state, or do inventory on it.

Many users want their start menu layout to be roamed, meaning they will get the start menu layout back when they reinstall their computer or log in to another computer. Starting with Windows 10 version 1703 Creators Update it is possible to roam the layout of the start menu using UE-V (User Experience Virtualization).

The start menu layout roaming with the UE-V template that I published over at the TechNet Gallery works best in scenarios where the devices have the same applications installed, otherwise the user will get shortcuts to applications that are not installed removed when clicking them.

NOTE: This is NOT an official solution and for sure an unsupported one. Let’s hope there will be a more supported solution from Microsoft in the future.

Download the UE-V template for start menu roaming in Windows 10 v1703 or later

When you have activated Credential Guard for Windows 10 (1607), you might note errors on your clients when they try to update group policies:

Windows failed to apply the {F312195E-3D9D-447A-A3F5-08DFFA24735E} settings.

You will also find thw below error in the DeviceGuard Operational event log:

Device Guard failed to process the Group Policy to enable Virtualization Based Security (Status = 0x80070057): Invalid parameter

The problem seems to be related to the incorrect registry value HypervisorEnforcedCodeIntegrity being written. It’s set to 3 on Windows 10 v1607, which seems to be a totally undocumented and invalid value. Verify under the key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard. This value is written as long as the setting “Virtualization Based Protection of Code Integrity” found in the GPO setting “Turn on Virtualization Based Security” is set to “Not configured”.

Solution

In the GPO setting Turn on Virtualization Based Security found in Computer Configuration\Administrative Templates\System\Device Guard edit the and set Virtualization Based Protection of Code Integrity to Disabled. This will make the HypervisorEnforcedCodeIntegrity turn to 0 and the GPO will apply without errors.

Ever wondered why the search feature in Windows 10 list the results as it does? Today I found a really interesting text file that shed more light on how some search results are listed.

One of my favorite tools in Windows is “Resource Monitor“. I use it all the time, basically every day to figure out what is going on in Windows, most of the times at the disk activity tab and watching what is going on (if things are installing, if something is being downloaded or what log files things are written to etc).

What I found today made me laugh and smile for quite some time. I found a text file containing app synonyms, and in there lies some explanation to why and how the search feature in Windows 10 lists search results as it does when searching for applications, apps and settings.

The funny thing is that it lists all common misspelling of some common applications. For instance, did you know that you can do a search for “exell” and it will display “Excel 2016” in the search results? You can also type “npo” to find “Notepad“, or type “c prompt” that will list “command prompt”, or “exx” that will find “Internet Explorer” or if you search for “ie” and it will list “Edge”.

The file where all these synonyms are gathered is named appssynonyms.txt and is located in C:\Users\%username%\AppData\Local\Packages\ Microsoft.Windows.Cortana_cw5n1h2txyewy\LocalState\ ConstraintIndex\Input_{3fe4e30f-3de5-44d2-b081-e763cc324698}

This is just hilarious, and it made my day 😊 Now I know another reason why Microsoft need to collect whatever the user types (when telemetry is set to “full”); To gather more misspellings and intel for this synonyms list.

Note: Also see settingssynonyms.txt in the same directory as the one above, where all aliases for finding control panels and settings are listed!

There are new WMI classes in Windows 10 that can be used to collect software inventory. The information can be displayed using PowerShell. Also, there is a feature that inventories what framework or runtime an application is dependent on, for instance which version of .NET Framework or Visual C++ Runtime and it can even see if there are dependencies for OpenSSL. Imagine having these feature in place when the HeartBleed bug appeared a few years ago.

Display all installed applications on a Windows 10 machine:

Get-WMIObject Win32_Installedwin32Program | select Name, Version, ProgramID | out-GridView

Display all apps and dependent frameworks on a Windows 10 machine for a specific application (replace the ProgramID in the filter section with another one from the above example), and make sure everything is on one row:

Get-WMIObject Win32_InstalledProgramFramework -Filter "ProgramID = '00000b9c648fd31856f33503b3647b005e740000ffff'" | select ProgramID, FrameworkName, FrameworkVersion | out-GridView

or to bake them together to get both the application name and associated frameworks:

$Programs = Get-WMIObject Win32_InstalledWin32Program | select Name,ProgramID
$result = foreach ($Program in $Programs) {
$ProgramID = $program.programID
$Name = $program.Name
$FMapp = Get-WMIObject Win32_InstalledProgramFramework -Filter "ProgramID = '$programID'"
foreach ($FM in $FMapp) {
$out = new-object psobject
$out | add-member noteproperty Name $name
$out | add-member noteproperty ProgramID $ProgramID
$out | add-member noteproperty FrameworkPublisher $FM.FrameworkPublisher
$out | add-member noteproperty FrameworkName $FM.FrameworkName
$out | add-member noteproperty FrameworkVersion $FM.FrameworkVersion
$out
}
}
$result | out-gridView

Now, happy hunting for runtime dependencies!

Those of you who know me know that I am somewhat stubborn and I never give up. This case could easily have gotten anyone to crack! This blog post shows a way to restore favorites from within a UE-V (User Experience Virtualization) package that UE-V cannot use to roam the favorites, as the package is considered invalid.

Problem

A user has created some 2346(!) favorites in Internet Explorer over the years. UE-V is used to roam favorites. After the user reinstalled the machine from Windows 7 to Windows 10, the favorites went missing.

Investigation

To start with, the package supposedly containing the favorites (MicrosoftInternetExplorer.common.pkgx) could still be found in the SettingsPackages folder and the size was 1,24MB and dated just a week ago. Those of you that have worked with UE-V know that a package that large signals that it contains a rather large amount data. Therefore, with that indication I assumed that the favorites is still lurking in there.

First thing to try was to just force the read of the package using via the UE-V agent as is the case whenever IE is started or closed, however Event Viewer revealed that UE-V thinks there is some kind of problem with the package.

The initial settings package for settings location template "MicrosoftInternetExplorer.common" is invalid. The initial settings package will be replaced with a new copy.

Now it is time to analyze the package itself. Note: This took quite some time to process by the cmdlet and it seems that the UE-V agents takes the same amount of time to process this large amount of favorites (~30 seconds).

Export-UevPackage c:\temp\MicrosoftInternetExplorer.common.pkgx | out-file C:\temp\ MicrosoftInternetExplorer.common.txt

Reading the output text file revealed that the user had 2346 favorites, data in the following format:

<SettingsDocument>
<file>
<Setting Type="VT_FILE" Name="file://{1777F761-68AD-4D8A-87BD-30B759FA33DD}\Folder1\Name of site 1.url" Action="Update">FEBB399A-8DF5-4B3D-B73D-A8167F61EB6B.pkgdat</Setting>
<Setting Type="VT_FILE" Name="file://{1777F761-68AD-4D8A-87BD-30B759FA33DD}\Folder1\Name of site 2.url" Action="Update">9FA223F9-F065-4269-B02C-E467A6B26459.pkgdat</Setting>
<Setting Type="VT_FILE" Name="file://{1777F761-68AD-4D8A-87BD-30B759FA33DD}\Folder2\Name of site 3.url" Action="Update">2393C0D8-AEDE-4D11-9CE3-E7E1E4B039CA.pkgdat</Setting>
...
…

Next up, rename the MicrosoftInternetExplorer.common.pkgx to MicrosoftInternetExplorer.common.zip and open it up. Note that you probably also would want to unblock the ZIP file before extracting the contents, choosing Properties and Unblock. Opening the PKGX as a ZIP shows us all the PKGDAT files listed in the output from Export-UevPackage. Extract the PKGDAT files to a folder, in my example c:\Temp\PKGDAT.

With these data sources, we have everything we need to recreate the URLs and their structure. Basically, what we need from the output from Export-UevPackage is the folder where the URL file is stored, the name of the URL file and the name of the PKGDAT filename.

Solution

With the aforementioned pieces of data, we can automate and match this to rebuild the Favorites entirely, using this PowerShell script:

$urls = (Export-UevPackage c:\temp\MicrosoftInternetExplorer.common.pkgx).split(“`n”) | select-string VT_FILE

foreach ($extracted in $urls)
{

$hash1 = $extracted -split ‘<Setting Type=|Name=|Action=|</Setting>’
$folder = $hash1[2].split(“\”)[1]
$urlname = $hash1[2].split(“\”)[-1].Replace(‘”‘,“”)
$pkgdat= $hash1[3].Split(“>”)[1]

New-Item c:\temp\RestoredURLs\$folder -type directory

if ($folder -match ‘”‘)
{
Copy-Item c:\temp\PKGDAT\$pkgdat c:\temp\RestoredURLs\$urlname
} else {
Copy-Item c:\temp\PKGDAT\$pkgdat c:\temp\RestoredURLs\$folder\$urlname
}
}

This recreated the favorites and in the same structure as it was! The user was indeed very happy!

Thanks goes to my colleague Jimmy Benandex who helped in making the above PowerShell command. As he mentioned there are better ways of doing the matching but I consider what we produced as a good enough solution :)

This is a schoolbook example of how to solve an annoying EXPLORER.EXE crash problem in just minutes. This guide can be used as inspiration for troubleshooting similar problems or for use with any application or process that crashes.

Problem

A user experienced a problem after upgrading Windows 10 version 1511 to 1607. Every time the user tried to open Windows File Explorer, it crashed, restarting the entire EXPLORER.EXE process. In the Application log in Event Viewer the following event was logged:

Faulting application name: Explorer.EXE, version 10.0.14393.479, time stamp 0x58258a90
Faulting module name: ntdll.dll, version 10.0.14393.479, time stamp 0x5825887f
Exception code: 0xc0000374
Fault offset: 0x00000000000f8283
Faulting process ID: 0x2428
Faulting application start time: 0x01d290d349d6a062
Faulting application path: C:\WINDOWS\Explorer.EXE
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: cf2ee514-f280-4942-8225-4c7fb440f27b

Investigation

As the problem above does not really tell us anything useful we need to obtain more information on the problem. On the machine which have the problem, start by activating the creation of crash dump files to get the information you need by setting the following registry values:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

Name: DumpFolder
Type: REG_SZ
Value: C:\CrashTemp

Name: DumpCount
Type: REG_DWORD (32-bit)
Value: 10

Name: DumpType
Type: REG_DWORD (32-bit)
Value: 2

Now reproduce the problem so that a crash dump is generated!

To analyze the problem we will be working with the Microsoft tool Windows Debugging Tools which can be downloaded for free from Microsoft (part of the Windows SDK), https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit (look for Get debugging Tools).

After installing Windows Debugging Tools, start it from the Start menu, it is called WinDbg (x86) or WinDbg (x64). To be able to get a result from the debugging of the DMP file and find the cause of the problem you will need the symbol files. These can be downloaded as one package but it is much more convenient to setup Windows Debugging Tools to download files as necessary. To set this up, in WinDbg, go to Open and choose Symbol file path. Now type a path to a directory on the hard drive, for example:

SRV*C:\symbolfiles*http://msdl.microsoft.com/download/symbols

Load and analyze the crash dump file
When the process crashes a snapshot of the memory is dumped to a file on the user’s computer.  This is the file that contains the key to the crash and to analyze it first open it by going to Open and then choosing Open Crash Dump. Before doing this copy the file to the machine where you will analyze this.

Browse to the location of the DMP file and choose to load it and if you get a question if you want to save the workspace you choose Yes. The necessary symbol files will now be downloaded from Microsoft. To get all the details about the crash you have to type:

!analyze -v

In this particular crash, we could instantly determine that the cause was thumbcache.dll.

Solution

As the problem was related to thumbnails cache, the first thing to try I thought was deleting the thumbnails cache. So I killed the explorer.exe process on the user’s machine and browsed to C:\Users\<username>\AppData\Local\Microsoft\Windows\Explorer and deleted the thumbnails cache files which are located there. Voila, the user could then start File Explorer once again without experiencing a crash!

It seems that some applications (none mentioned and none forgotten) create services where the path to the service is written with forward slashes. The migration engine in Windows 10 does not recognize this as a valid path and therefore do not migrate those services and they are thereby missing after upgrade.

The following can be found in the setupact.log (located in C:\Windows\Panther) after upgrading Windows 10 to a new build:

2017-02-07 16:07:42, Info       [0x08056f] MIG    Start processing unit="Services"
2017-02-07 16:07:42, Warning               MIG    CAddSystemServicesExpander::ExtractImagePath: Failed to extract file path from APP_Service::ImagePath=["C:/Program files/Vendor/Product/APP_Service.exe"]

The solution is to make sure the application is installing the service with a path that contain backslashes instead of forward slashes.

After filing this as a bug the first time in November 2015, as of February 6th 2017 the fix for searching for Internet shortcuts (LNK and URL files) placed in the start menu is here at last! Now when doing a search in all Windows 10 editions (1511, 1607 and the latest and upcoming Red Stone 2 build a.k.a. “Creators Update”) internet shortcuts (i.e. links to web applications) are returned in the search results as one would expect.

There are a few things to note though:

1. The change is done by the Bing team and it is a server side update. This means the search components are updated in the background automatically, unless you are blocking silent updates.
2. Only LNK and URL files that are placed in the start menu are returned in search. That is C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs or C:\ProgramData\Microsoft\Windows\Start Menu\Programs.
3. You must make sure the GPO “Don’t search the web or display the web results in Search” is set to “Disabled” or “Not configured” (located in Computer Configuration\Administrative Templates\Windows Components\Search).

Thank you Microsoft!

A cause of error 0x80070241 when upgrading a Windows 10 to Windows 10 build is that you may have the latest Windows ADK Insider Preview (build 14965) installed. The solution is to uninstall the Windows ADK Insider Preview and then perform the upgrade. The issue is caused by some interference with the DISM tool, and the setuperr.log points to problems mounting the WinRE.wim file. This occurred trying to upgrade from Windows 10 build 14971 with Windows ADK 14965 to Windows 10 build 14986.