The Experience Blog

A blog with focus on experiences with the Windows Client operating systems…
RSS icon Email icon Home icon

  • Checking Win32 application runtime dependencies in Windows 10

    Posted on March 17th, 2017 By Andreas Stenhall + No comments

    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!

  • Restoring Internet Explorer favorites from an invalid UE-V package

    Posted on March 2nd, 2017 By Andreas Stenhall + No comments

    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 :)

  • How to solve a crashing File Explorer (explorer.exe) in Windows 10

    Posted on February 27th, 2017 By Andreas Stenhall + No comments

    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!

  • Application services not migrated when upgrading from one Windows 10 build to another when path contain forward slashes

    Posted on February 14th, 2017 By Andreas Stenhall + No comments

    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.

  • URL and LNK files now searchable in Windows 10 search (Cortana / Start menu search)

    Posted on February 8th, 2017 By Andreas Stenhall + No comments

    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!

  • Error 0x80070241 when upgrading Windows 10 build to build

    Posted on December 9th, 2016 By Andreas Stenhall + No comments

    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.

  • Windows 10: How to figure out what the blue screen of death is caused by

    Posted on December 9th, 2016 By Andreas Stenhall + No comments

    Having deployed many thousands of Windows 10 machines over the last year I must say that I am surprised by the large number of blue screens that have occurred and still occur on Windows 10. As always, hardware issues surface when deploying a new OS, but the vast majority of blue screens that occur are actually caused by bad drivers.

    Things are shaping up and nowadays Windows 10 and its drivers are more stable then a year ago but still there are quite a few blue screens caused by primarily bad graphics drivers and not to mention WiFi drivers from the most prominent chipset maker in the business.

    Therefore I have made some updates to this popular guide – troubleshoot and analyze blue screens of death – how to figure out what the infamous blue screen of death is caused by.

    Updating drivers on an active basis is very much necessary in terms of deploying and managing Windows 10 if you want to keep blue screens away!

  • Microsoft changes search feature in Windows 10 v1511 using sneaky background delivery options – this is Microsoft “Searchgate”!

    Posted on August 12th, 2016 By Andreas Stenhall + 1 comment

    So in Windows 10 1511 and 1607 I have an issue with searching for internet shortcuts as outlined in this blog post. For Windows 10 1607 things seemed to get worse. But, then I noticed in Windows 10 version 1511 as well that all of a sudden “Search my stuff” was gone although it had been there before! The investigation reveals some interesting stuff and magic things happening in the background!

    SHORT SUMMARY: Microsoft is pushing Windows 10 1607 (Current Branch) search features to Windows 10 2015 LTSB and Windows 10 1511 (Current Branch for Business) silently and in the background without any announcements made.

    Search in 1511 (as when Windows 10 entered Current Branch for Business and as long it has not been connected to the Internet):

    1

    Investigation

    1. I installed Windows 10 1511 (media updated in april 2016) in a VM – with no Internet connection. Note: system language is set to Sweden (Swedish) during install.
    2. I logged in and noticed that “Search my stuff” was there.
    3. I then thought I’d connect the machine to Windows Update to get the latest CU and see what happens after that. But before I knew it, “Search my stuff” vanished just after connecting the machine to the Internet. Now, things are getting interesting!

    Further investigation

    1. I installed Windows 10 1511 (media updated in april 2016) once again in a VM – with no internet and system language set to Sweden (Swedish).
    2. I logged in and noticed that “Search my stuff” was there.
    3. Checkpoint created in Hyper-V :)
    4. Fired up good old Resource Monitor.
    5. Connected the VM to Internet.
    6. AS SOON AS I CLICKED THE WINDOWS FLAG IN WINDOWS  – things started to happen in the background!
    A process named BackgroundTransferHost.exe started to download new packages, including what seemed to be new and updated code for the Shell and Cortana!

    2
    7. When it finished downloading – Voílà – the search box in Windows 10 1511 looks very much a lot like in 1607 and yes, the option “Search my stuff” is gone.

    3

    Conclusion

    This raises more than a few questions:

    What else is changed using this background delivery manager? Can we expect the start menu in 1511 to look like 1607?

    Is background delivery the reason why MS always writes “No new operating system features are being introduced in this update” on any CU:s released? I mean, “no new features are introduced in the CUs but we will gladly publish (new and) changed features unannounced using other delivery technologies than Windows Software Update packages (CUs)”. (https://support.microsoft.com/en-us/help/12387/windows-10-update-history )

    I thought the whole idea of different builds (1507, 1511 and 1607) would mean no feature changes and especially no new feature changes which are completely unannounced or did I miss this announcement in feature change?

    Is Windows 10 LTSB affected by this as well? UPDATE! Windows 10 2015 LTSB is affected by this as well which should be troublesome for Microsoft as Cortana is not supposed to be there and it is supposed to be feature locked.

    Does this mean you can easily deploy a feature change/fix to my machine so that internet shortcuts are returned in the search results?

    No further questions on this – I’m still shocked!!!

  • Internet shortcuts and search in Windows 10 v1607 – it’s getting worse!

    Posted on August 5th, 2016 By Andreas Stenhall + 1 comment

    This is a follow up to the post “Internet shortcuts in the Start menu not returned in quick search in Windows 10“. The plot thickens quite a lot with Windows 10 v1607.

    UPDATE February 8, 2017: The fix is out! Read more in this blog post: LNK files now searchable in Windows 10 search (Cortana / Start menu search) 

    UPDATE August 21, 2016: In a newly opened support case with Microsoft they have come to the conclusion that this is a code defect and will be fixed, for both LNK as well as URL files. Question is when it will be fixed, and (*irony*) if it will be distributed quickly in the background using the sneaky update method I wrote about in a recent blog post.

    UPDATE August 12, 2016: It seems that Microsoft has also introduced this change in Windows 10 v1511! The option “Search my stuff” in the search box in the start menu and task bar is long gone! Read more about the sneaky update of the search feature in not only 1511 but also 10240 (CBB and LTSB).

    Scenario

    It is no secret that web applications become more and more common for every day that passes and that has been the case for many years now. I know Microsoft wants and thinks that everyone is now turning all their Line of Business applications into modern apps but that’s just not the case just yet. This is a fact on how it looks in the real world. With that said, the problem here is that Internet shortcuts in the start menu that points to a URL is listed in the Start menu list of applications but they are not searchable in the Windows search feature.

    Now things get interesting and at the same time worse! In Windows 10 v1511, you can search for an internet shortcut by typing its name and then choosing “Search my stuff”. In 1607, this option is gone. So without applying any workarounds the user must go back to find the web application by manually browsing through the long applications list in the start menu. So, with that we can tell all the users we for 10 years have tried to learn to use the search feature now to go looking for applications manually in the start menu. Well done Microsoft!

    Lapse in logic? I and users expect that whatever application can be seen in the start menu (EXE, modern apps or web apps) is also found when doing a search! As described above, this is not the case in Windows 10 version 1607.

    Workarounds

    Yes, there are workarounds, but only crappy ones.

    • You can exchange all LNK and URL:s and point them to iexplore.exe URL, i.e. “iexplore.exe http://www.microsoft.com”. This is what Microsoft recommends. Hmm, well is that a good solution? So when the customer wants to switch their standard browser will this workaround be a good idea? This workaround kind of defeats the idea of defining standard programs and URLs open in the browser defined as the standard program. I try to make my customers Windows client environments less complex and more standardized but this workaround points in the opposite direction to that.
    • You can also instruct the users to open the web site in Internet Explorer 11 and choose “Add Site to Apps”. By doing that you get a shortcut with the extension .website which is listed in the Start menu AND apart from that also being indexed and searchable! Is it possible to create these .website files and distribute? Not quite, as these were invented for IE9 where users could pin websites to the Task Bar, and are intended to be pinned by the user, not programmatically. Also, .website files are always opened only in Internet Explorer regardless if you set the OS standard browser to Edge or some other browser.

    Summary

    To sum it up, am I the only one having customers with internet shortcuts in the start menu? The reason they are there is that I do not want users to have to distinguish if a Line of Business application they use for their daily work is a EXE file or a web application (or a modern app for that matter). I expect them all to be treated the same as well as existing in the same place. I expect that EXE applications are returned in the search results. I expect modern apps to be returned in the search results and I expect web applications (internet shortcuts) to be returned in the search results.

    That is just simple logic in my world but who knows, I might be all crazy. I know 10000+ users that must think Microsoft are crazy when they are forcing users to go back to manually finding stuff instead of using search!

    Solution

    There is no solution so I appeal to Microsoft and specifically the Search team, that you repair the lapse in logic that exist in the current implementation in Windows search in Windows 10 1511 and 1607!

  • How to disable the Mobile hotspot feature in Windows 10 1607 using GPO or MDM

    Posted on August 4th, 2016 By Andreas Stenhall + No comments

    In Windows 10 v1607 Anniversary Update there is a brand new UI for sharing your internet connecting and creating a mobile hotspot. The feature has been there in Windows before but has previously required administrative privileges to activate. Starting with Windows 10 v1607 this is exposed in the modern interface under Network > Mobile Hotspot and can be activated as a standard user, posing a security threat if you for instance have network security in place which can then be circumvented.

    Solution

    Using GPO, you can disable Mobile Hotspot in the UI by settings the GPO setting Prohibit use of Internet Connection sharing on your DNS domain network to Enabled. This settings is located under Computer configuration > (Policies) > Administrative templates > Network > Network Connections.

    If you are using MDM, you can also configure this with this setting:

    URI full path: ./Vendor/MSFT/Policy/Config/WiFi/AllowInternetSharing
    Data type: Integer
    Allowed values:
    0 – Do not allow Internet Sharing.
    1 – Allow Internet Sharing (default)

    Result when this setting is changed wither via GPO or MDM:

    MobileHotspot