[German]Microsoft has begun to distribute the feature update on Windows 10 November 2019 Update (Version 1909) more widely. The Windows 10 Update Wizard has been adjusted accordingly and the feature update is now officially available for WSUS.

Update Assistant supports Windows 10 Version 1909

I had already seen it on Askwoody a few days ago: The announcement that Microsoft plans to update its Windows 10 Update Assistant this week to support an upgrade to Windows 10 version 1909. As of November 18, 2019, KB3159635 has been updated to include the following information.

The Windows 10 Update Assistant downloads and installs feature updates on your device.  Feature updates like Windows 10, version 1909 (a.k.a. the Windows 10 November 2019 Update) offer new functionality and help keep your systems secure.

The Update Assistant can be downloaded here. The following figure shows the relevant download page – the Update Assistant is downloaded via the upper Update Now button.

Note: The download for Update Assistant appears only if the Microsoft page is opened in a browser under Windows 10. In previous Windows versions only the Media Creation Tool is offered via the button Download Tool Now. The MCT allows you to download an installation image of Windows 10 and put it on DVD or USB stick.

The program must be launched from Windows 10; it helps users who do not want to wait until a feature update is offered via Windows Update. This is the case, for example, when Microsoft believes that compatibility problems exist on a machine.

After startup, a wizard checks the compatibility of the system with regard to the supported feature update and reports any compatibility issues. If there are no compatibility issues found, the wizard guides the user through the steps to install the feature update. The wizard currently supports Windows 10 Version 1909.  

Windows 10 V1909 available via WSUS, WUB

Furthermore, Microsoft has officially started distributing the feature update via Windows Update for Business (WUB) and via WSUS since November 12, 2019. Blog reader Karl has notified me about a corresponding article via Twitter.

Alright let the magic begin.#staycurrent https://t.co/TpUk1bAQpa

— al Qamar (Karl Wester-Ebbinghaus) (@tweet_alqamar) November 19, 2019

I already got some comments from German readers in my blog last week that Windows 10 V1909 had arrived as a feature update in WSUS. But I became aware of this Techcommunity article via the above tweet.  The article announced the availability of Windows 10, version 1909 via Windows Server Update Services (WSUS) and Windows Update for Business. It is also available for download through Visual Studio subscriptions, from the Software Download Center (via the Media Creation Tool), and from the Volume Licensing Service Center (VLSC).

Microsoft has now released the .admx templates (Administrative Templates (.admx) for Windows 10 November 2019 Update, Version 1.0) with Group Policy for Windows 10 Version 1909 in their final form.

I have just become aware of this information via the following tweet.

Download Administrative Templates (.admx) for Windows 10 November 2019 Update (1909) from Official Microsoft Download Center https://t.co/msRbRTGN2B

— Sune Thomsen (@SuneThomsenDK) November 15, 2019

These templates have the release date 11/14/2019 and can be downloaded from this Microsoft download page. The templates imported into the Group Policy Editor allow administrators to manage registry-based policy settings. The download includes the Administrative Templates (.admx) for Windows November 10, 2019 Update (1909) in the following languages:

• cs-CZ Czech – Czech Republic
• da-DK Danish – Denmark
• de-DE German – Germany
• el-GR Greek – Greece
• en-US English – United States
• es-ES Spanish – Spain
• fi-FL Finnish – Finland
• fr-FR French – France
• hu-HU Hungarian – Hungary
• it-IT Italian – Italy
• ja-JP Japanese – Japan
• ko-KR Korean – Korea
• nb-NO Norwegian (Bokmål) – Norway
• nl-NL Dutch – The Netherlands
• pl-PL Polish – Poland
• pt-BR Portuguese – Brazil
• pt-PT Portuguese – Portugal
• ru-RU Russian – Russia
• sv-SE Swedish – Sweden
• tr-TR Turkish – Turkey
• zh-CN Chinese – China
• zh-TW Chinese – Taiwan

Microsoft  has released the Windows 10 Insider Preview Build 190128 (from the development branch 20H1) for Windows Insider in the Fast Ring on November 19, 2019. Only error corrections have been made, Microsoft is striving for the completion of the build. Details about the fixes can be found in the Windows Blog.

On 15.11.2019 Microsoft had released the Windows 10 Insider Preview Build 19025 (20H1) in the Fast Ring for insiders (see Windows 10 Insider Preview Build 19025 (20H1) in Fast Ring). Now this version has also been released for the Slow Ring. Details about the fixes and new features (e.g. the Windows search has been improved) can be found in the Windows Blog.

[German]A little supplement to the November 2019-Patchday. Microsoft has fixed the problem caused by an October update with the Windows Defender ATP error 0xc0000409 under Windows 10 version 1809 with a cumulative update from November 2019.

What is the Windows Defender ATP issue about?

In enterprise environments, Windows Defender Advanced Thread Protection – an advanced security solution from Microsoft – can be optionally booked. There is a problem with KB4520062 for Windows 10 Version 1809, which was released as an optional update on October 15, 2019 (see Windows 10 Updates (10/15/2019)).

The Microsoft Defender Advanced Threat Protection (ATP) service can stop and no more data is transferred to the cloud. In addition, the error code 0xc0000409 for MsSense.exe is entered in the Event Viewer. Microsoft resolved the issue on October 18, 2019 by revising the support post as Known Issues for this update:.

After installing this update, the Microsoft Defender Advanced Threat Protection (ATP) service might stop running and might fail to send reporting data. You might also receive a 0xc0000409 error in Event Viewer in MsSense.exe.

Microsoft promised a solution by mid-November 2019 and recommended affected administrators not to install the update on the devices in an affected environment. I had reported about this issue in the blog post Windows 10 V1809: Defender ATP erzeugt Fehler 0xc0000409 nach Update KB4520062, but forgot that topic.

The Windows Defender ATP bug has been fixed

The cumulative update KB4523205 was also released on November 12, 2019 (see Patchday Windows 10 Updates (November 12, 2019)). The following note can be found in the list of fixes:

Addresses an issue that might cause the Microsoft Defender Advanced Threat Protection (ATP) service to stop running and stop sending reporting data.

I only noticed it briefly, without having established the connection to the article Windows 10 V1809: Defender ATP erzeugt Fehler 0xc0000409 nach Update KB4520062,. Bleeping Computer noticed that the error described above was fixed.

[German]Some users are annoyed by a strange behavior. The shutdown is blocked by a strange app ‘G’ – which makes many suspect a malware infection. It is simply a Windows bug that will soon be fixed.

The error in detail

If you search the Internet for the term ‘App G prevents shutting down’, there are hundreds of hits. The error runs from Windows 7 to Windows 10 through the operating system versions. On reddit.com there is this post for example:

App called “g” is preventing shutdown or restart

Every once and a while there’s this app called “g” that prevents my pc from shuting down but I have no idea what it is , does anyone have and idea on what tjis could be?

A user complains that an app named G interferes with the shutdown process. Another user confirms this in the same thread. This reddit.com post describes the same thing. bestätigt das Ganze im gleichen Thread.

The screenshot above shows this display during shutdown. The whole thing is described at superuser.com in this article.  

App is preventing shutdown or restart

After updating my Windows 10 to creators update (build 15063.138) when I restart or shutdown the PC a screen appears and shows a ‘G’ app which is preventing the operation.

Is there a way to determine which application it is, or find out more details about it?

I do not see any “g” running process or installed application in my system.

Also in the Steam-Community, in Microsoft Answers forum (here and here) the problem is reported without a solution being found. There is also a German reddit.com thread on the topic. As a rule, those affected are advised to check the system for malware. At Bleeping Computer, for example, you can find this forum thread with such hints. 

A Bug in Windows

The error has passed me by so far – but Woody Leonhard found the cause and described it in this  Computer World article. Also Woody noticed that there are hundreds of hits on the internet where the problem is described. People are sent to search for malware, but this is without result.

The reason: The whole thing is simply a bug in Windows that has been running for years through various versions. Raymond Chen of Microsoft described the background in the Microsoft developer blog in the article The program “G” is preventing you from shutting down.

Microsoft’s developers have noticed some time ago that treating a UTF16-LE Unicode string as an 8-bit string generally takes only the first character. This is because the higher byte of the UTF16-LE code unit is zero for most Western European characters and the zero byte is interpreted as the end of the 8-bit string.

Let’s get back to the mysterious “G” program, which blocks the shutdown. When the GDI+ library was created, it had to support Windows 98. However, Windows 98 had very limited support for Unicode. So everything was compiled as ANSI and used the ANSI versions of functions like RegisterClass, CreateWindow and DefWindowProc to create and manage help windows. The lack of Unicode support in the helper window didn’t cause any problems since the window never displayed a user interface and never processed text. The window was there to do things like listen to WM_SETTINGSCHANGE messages so it knew when to invalidate its caches.

Later, most of the GDI+ library was recompiled simply as a Unicode component, not as an ANSI component. However, the notification window procedure contained an explicit call to DefWindowProcA. Most character set mismatches are detected by the compiler due to a type mismatch. However, the font dependency in DefWindowProc is not encoded in the parameter types. Therefore, this discrepancy was not detected by the compiler.

This discrepancy was also not detected during testing, since the notification window does not output any text. The title of the window “GDI+ Hook Window” was simply truncated to “G”. But since this title is not used for anything, it didn’t matter, the window title is never displayed to the user. Only if the program hangs at shutdown, the truncated string G is used. The error described above is noticed.

A Fix comes for Windows 10 20H1

Microsoft’s developers have included a fix for the problem in the announcement of Windows 10 Insider Preview Build 19013. Jen Gentleman pointed this out in this tweet at the end of October::

Have you ever tried shutting down, and seen a message saying “G” is preventing the operation, and thought “What is G? “

We investigated this, and found…https://t.co/RBzWGnEt0F#WindowsInsiders pic.twitter.com/0sDJHkgIZv

— Jen Gentleman (@JenMsft) October 29, 2019

The change log for the insider build 19013 already contains this reference to the correction of the bug:

Some of you have reached out about when trying to shutdown, seeing a message saying that an app named “G” was preventing shutdown. We investigated and found an issue where windows related to GDI+ were only referenced as “G.” We’ve fixed this, so going forward, these will now have the name “GDI+ Window (<exe name>)”, where <exe name> will show the .exe name of the app using GDI+.

So a fix exactly the error mentioned above, so that from the Windows 10 release in spring 2020, the application that hangs on shutdown will also be correctly named. 

[German]Just a brief information about a crude behavior of Windows 10 November 2019 update. Just got a case under my eyes, where someone allegedly got the version 1909 without approval for the installation of the feature update. But it’s not that easy, it looks to me as if bits are jammed.

Strictly speaking, it looks to me as if the software plumbers from Redmond don’t really get their bits & bytes sorted out in a proper manner anymore.

Windows 10 V1903 and V1909 share the same code

I’ve discussed it within my blog post Windows 10 V1909 released, how to get this update? Microsoft had the idea to provide the same updates for Windows 10 Version 1903 (May 2019 Update) and Windows 10 Version 1909 (November 2019 Update). Those who already work with Windows 10 Version 1903 will have the code for Version 1909 already on their hard disk. The distinction between the two Windows 10 versions is made only by the build number.

• Windows 10 Version 1903 uses Build Number 18362.xxx
• Windows 10 Version 1909 uses Build Number 18363.xxx

To upgrade from Windows 10 Version 1903 to Windows 10 Version 1909 you need an Enabler Update (KB4517245). This unlocks the relevant features for the Windows 10 November 2019 update and changes the build number from 18362 to 18363.

The enabler update KB4517245 is offered to users in Windows Update as a feature update to Windows 10 Version 1909. The download and installation must be initiated explicitly via Download Now and Install link. 

A crude case: Windows 10 V1909 without approval

At askwoody.com I became aware of a crude case. Tero Alhonen hat documented it at Twitter with screenshots (see below).

??? pic.twitter.com/BReFDX63XH

— Tero Alhonen (@teroalhonen) November 21, 2019

Tero Alhonen says that although he is a Seeker (he had searched in Windows Update), he never agreed [to Download and install now] to install the feature update. Nevertheless, he was suddenly offered a reboot to install the feature update on Windows 10 Version 1909 on the Windows Update page (top screenshot in the tweet above).

But it gets even crazier, as the screenshots in the lower tweet show. The update history page indicates a successful installation of a Feature Update to Windows 10 Version 1909 on November 21, 2019 on that machine. . But it gets weird when you look at the version value shown in the screenshot. Winver reports build 18362.418, which is Windows 10 version 1903 according to my explanations above.

So what Tero Alhonen has on his system is somehow not Windows 10 Version 1903, but also not Windows 10 Version 1909. It seems that some bits are jammed pretty well. Or it’s a big joke from Tero – who knows.

[German]Currently Microsoft confuses users once again with a nasty behavior when reinstalling a Windows 10 Home Version 1909. Some users only have the option to create a Microsoft account – a create local account option isn’t offered. However, this limit can be handled with a simple trick.

What’s the problem?

At the end of September the topic already popped up in Windows 10 Insider Preview Build 18363. A US user had noticed that he could no longer set up a local user account when reinstalling the Windows 10 Home Preview. He was forced to set up a Microsoft account during setup. He had posted this behavior on reddit.com.

Some sites covered this story, but I had not addressed it here within my blog, because I didn’t find another source of this behavior. And my German MVP colleague Martin Geuß had executed also a test with a German version of this Insider Preview for Windows 10 Home. In this article he came to the conclusion that nothing had changed.

Later I found out that Microsoft had done an A/B test with US-Windows insiders. There were probably only a few people who saw this behavior at all. This explains why only one person on reddit.com reported this. Since there was no such behavior in the other insider builds, this topic became out of my view.

Thurrott found again the forced  ‘MS account’ setup

US blogger Paul Thurrott wanted to document the setup steps for a new installation after the release of Windows 10 Version 1909 and then came across a curiosity. While the professional version of Windows 10 November 2019 Update (Version 1909) only showed minimal changes in the OOBE phase, Windows 10 Home V1909 had an anomaly. There he suddenly no longer had the option to create an offline account (standard user account).

(US OOBE dialog to set up a first account, Source: Thurrott/Dr. Windows)

The picture above shows the OOBE page whether the option from earlier Offline Account Windows 10 versions is missing.

Just a tip: If the user prevents an Internet connection before launching the setup, the OOBE page shows the option for setting up an offline account as usual. The setup then falls back to this position.

And in Windows 10 Pro and Enterprise, the OOBE account setup hasn’t unchanged from the previous versions anyway.

Does this only apply to US users with Windows Home?

I knew from Martin Geuß that he had intensively tested the behavior in the Insider Preview. So I found quickly his new German article Windows 10 November Update: US-Version “zwingt” zum Microsoft-Konto at Dr. Windows. He did a new install test again and found, that he has the option to create a first local account in Windows 10 Home 1909. It’s like the Insider Preview: Users with German language pack still get the option to set up a local account during setup – no matter if a Home or Pro edition of Windows 10 V1909 is reinstalled.

That was the point, where I assume, it affects only US users. But at this point I have to correct myself – as the comments of several readers of this blog and at German magazine heise show, some useres with a German Windows 10 Home V1909 also seem to be affected.

Just a side note: It has always been difficult to recognize the option to create a local user account during setup, because the option is drawn in blue ink on a blue background. So I’m not sure, if some users overlooked this option. But the screenshot shown above clearly say, there is no local account option.

For me, it remains unclear at this point what’s Microsoft’s strategy? For Microsoft Germany, such a move is only water on the mills of the ‘Windows 10 is not DSGVO-compliant and Microsoft cannot be trusted, they want to force us into the cloud’ discussion. At this point I may link to the German article Die tickende DSGVO-Zeitbombe von Microsoft of the colleagues from Golem, who bring the problem to the point.

What’s Microsoft’s credo? ‘We wan’t to be as clear and transparent as possible’. Good joke I guess.

[German]Within this blog post I would like to cover some insides about the the development and delivery of Windows 10, version 1909. The Microsoft Insider Team has revealed some information in a webcast session. Here is now a quick excerpt for readers in a hurry.

Background: Insider Webcast

From time to time, the Microsoft Insider Team holds so-called webcasts for Windows Insiders. There Microsoft developers take part and give insight into their work. I myself regularly miss these webcasts (forget it, no time/to time consuming etc.). And if the information is under a non disclosure agreement (NDA), it’s not helpful for me as a blogger. Yesterday, November 21, 2019, another insider webcast took place, which can be viewed now in the mixer channel. 

In yesterday’s insider webcast the team told about how complicated this change was underneath and they have no fixed plans to keep it up like this every year.
So H1 feature / home targeted
H2 fixing business targeted.

THERE IS A BIG BUT however:
They TRY to keep it like that

— al Qamar (Karl Wester-Ebbinghaus) (@tweet_alqamar) November 22, 2019

The above tweet by blog reader Karl directed me to take a quick look at the recorded webcast. Since the webcast can now be accessed publicly, I no longer see myself bound by my NDA. Therefore I have summarized the whole thing in a few sentences of text and reproduce the following compressed.

Delivery Options for Windows 10 Version 1909

In the webcast, Microsoft developers addressed the following questions related to Windows 10 development. The core point are the changes in 19H2 Delivery, e.g. the way the Windows 10 November 2019 update is rolled out.

Microsoft had already announced during the release of Windows 10 May 2019 update, that the feature update for Windows 10 19H2 will be made via Windows Update as a ‘normal update’. The following slide shows the key points that are new in the feature update to the development branch 19H2 (Windows 10 V1909).

I had already explained in various blog posts (e.g. Windows 10 V1909 is called November 2019 Update and Windows 10 V1909 released, how to get this update?) some details. Microsoft rolls out the same updates for Windows 10 Version 1903 and Version 1909. So both Windows 10 builds have the same code internally. All you need now is a Enablement Update (KB4517245), which unlocks the relevant features for the Windows 10 November 2019 update. 

This package is offvered via an update search as a Feature update for Windows 10, version 1909 – an optional update (see figure above). The download and installation of this feature update need to be initiated explicitly via the Download and Install Now hyperlink. So not much has changed for a user, compared to the delivery of the feature update to Windows 10 version 1903.

Behind the scenes, however, this has resulted in enormous changes, as the above slide illustrates. If earlier Windows 10 feature updates still transfer packages up to 3.5 gigabytes in size, the 19H1 development branch will be different. Windows 10 Version 1903 already has the code of Windows 10 Version 1909, but the new features have not yet been released. Without the last cumulative update a maximum of 330 MByte will be downloaded in a feature update install. If all cumulative updates are already available, the enabler update needs a maximum of 180 KB to download. The entire update process from Windows 10 Version 1903 to Version 1909 should run much faster than an earlier feature update. The prerequisite, however, is that all cumulative updates are already installed on Windows 10 Version 1909.

Note: When switching from Windows 10 Version 1809 or earlier, nothing changes for the feature update – you still have to download the 3.5 GByte. But I had already explained this in the blog in various articles.

What does it look like for WSUS?

In the following slide, the developers summarize the situation for administrators in corporate environments who manage updates via Windows Server Update Services (WSUS).

For upgrading older builds prior to version 1903, WSUS does not change anything from earlier builds. All options to roll out the new Windows 10 version 1909 are still available. For the Windows 19 Version 1903 development branch 19H1, ISO and ESC installation media are available to roll out Windows 10. So there is nothing new there either. To upgrade to Windows 10 Version 1909 (19H2) from Windows 10 V1903, WSUS also offers the Enablement Package as Update KB451724. The advantage there is also that the package size is very small and the upgrade of the clients is faster.

Advantages of the new approach and other questions

The developers summarize the new approach to rolling out the 19H2 feature update in the following slide. A system running Windows 10 May 2019 Update (version 1903) requires less than 25 megabytes of disk space to migrate to version 1909. This is ultimately the cumulative enablement update that is saved.

However, it is important that the internal system files are still up to date with build 18362. Only Winver, WMI and the API calls for version queries provide the build 18363.

This could explain the behavior outlined within the article Windows 10 V1909: Strange Update Status …. Bits jammed? – something hasn’t been changed cleanly yet.

Will this delivery be used in future?

In the webcast, the developers then answer the question as to whether they want to keep this delivery option in future and where the challenges of the new experiment were. The following slide summarizes it. The development of the Windows 10 version 1909 with delivery as a cumulative update was a ‘pilot project’!

There are no formal plans to do this in the future. Rather, one observes the feedback now and then decides whether it was a crazy idea and can go away or be retained. So it is the admission of an ‘open-heart operation’ by the willing Windows 10 users – regardless of whether they are private or corporate customers. Courageous, courageous.

When a device is not offered a feature update

In the second question from the above slide it is again clarified why a device is not offered the Windows 10 V1909 Feature Update. All recommended updates must be installed on the Windows 10 client before the Enablement Update is offered. However, the company wants to optimize this in the next few months.

In case of compatibility issues, Microsoft can set an upgrade stopper anyway, but this can then be used for Windows 10 Version 1903 and 1909.

Huh, pant’s down: Surgery on an open ‘Windows heart’?

In another slide the team let ‘the pants down’. The project was probably not that simple and elegant as thought. The slide below contains the core statements of the team. It was early clear that Microsoft (after the disaster with the delivery of the Windows 10 versions 1803 and 1809) had to come up with something different for feature update delivery. The rough idea was to roll out the feature updates in autumn as ordinary updates.

In retrospect, however, this proved to be the biggest challenge in Windows 10 development. How do you get the code for the V1903 and 1909 to be the same, but the 1909 version shows the correct version? And this even though the files remain on build 18362? It took the developers five months to find the variant the have chosen between now different design options and implement the customizations.

On the one hand, I take my hat off to the developers and their ideas. On the other hand, it shows how shaky the Windows as a Service development can be. Every decision I made may be prove wrong within a year. Then the team has to put their energy into a solution to fix a wrong decision – and is grounded for other things. 

More unstable network connection in 19H2?

In the last slide, the developers answer the question of various users that the network in build 19H2 of Windows 10 has become more unstable. Since the code of the V1903 and 1909 is the same, nothing has changed internally for Windows 10.

The developers therefore assume that there is still a bug that must already be included in Windows 10 Version 1903. Those with network problems should run the Network Troubleshooter and make sure that all network drivers are up-to-date.

Similar articles
Windows 10 19H2: What could change
Windows 10 V1909 is called November 2019 Update
Windows 10 V1909 released, how to get this update?
Windows 10 V1909: Available via WSUS and Update Assistant
Windows 10 V1909: Strange Update Status …. Bits jammed?
Windows 10 V1909: Missing local user account during setup
Windows: App ‘G’ blocks shutdown

On November 22, 2019 Microsoft released the Windows 10 Insider Preview Build 19030 (20H1) in Fast Ring for insiders. It is a bug-fix release because Microsoft is working towards the final. The watermark has been removed. Details about the fixes and open issues can be found in the Windows Blog.

On November 22, 2019 Microsoft released also update KB4531955 for Windows 10 Insider Preview Build 19025 (20H1) in Slow Ring for insiders. It raises the build to 19025.1052. According to the addendum within the Windows Blog, there are no changes. Microsoft is testing the service pipeline.

[German]Windows 10 users who are upgrading to Acronis True Image 2020 may facing an unplesant bug. Suddenly the Windows System Restore is bricked and can’t create restore points anymore.

Upgrade to Acronis True Image 2020 bricks system restore

German blog reader Gerhard F. contacted me last Thursday via mail and pointing to an issue he was facing in Windows 10 after upgrading to Acronis True Image 2020. He wasn’t able to create a restore point in Windows System Restore anymore. Gerhard detected this immediately after the upgrade and wrote:

It’s about the restore point in Win 10. I’ve had the problem before not being able creating a restore point.

He also had in the previous case the problem that he couldn’t start Windows anymore. So he installed a backup created with Acronis and the system restore worked again. At that time, he was able to find the cause (missing filter driver entries). Now the error of a bricked system restore was back again. He wrote:

After updating to True Image 2020 I noticed that the system restore was not working again. Then I searched and found the [below mentioned] Acronis article. Since I didn’t do anything else, it could only be due to this update. The two entries in the upper filter were missing.

Background: From the earlier mentioned case he knew the problem that in the filter driver entry for file accesses in the registry was broken. The entries volsnap and fltsrv were missing in the value UpperFilters. These value can be found in the registry under:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\
{71a27cdd-812a-11d0-bec7-08002be2092f}

Without the correct  filter driver entries, the Writer cannot enter recovery points.

Note: This is a well know issue in ATI. After the upgrade to ATI 2019 the system recovery broke (see this forum post). For Acronis True Image 2020 there is this forum post, which deals with the error ‘volsnap driver not found’ during backup. Blog reader Gerhard wrote me that he hadn’t tried to make a backup with ATI 2020, but assuming the same root cause.

Acronis lists the bug as fixed

Blog reader Gerhard send me a link to an Acronis Support article, dealing with release notes and fixes for Acronis True Image 2020 Update 2 for Windows, Build 22510, dated November 21, .2019. There is the following hint:

TI-174833 – During a backup operation, the error message “No Volsnap driver found” appears even though the Volsnap driver is present.

Acronis lists this error, which is due to missing filter driver entries, as fixed in build 22510 of ATI 2020 Update 2.

Manual check the filter driver entries

If you  still suffer from the issue after installing Acronis True Image 2020 Update 2 for Windows, Build 22510, you should check the registry entries. Gerhard restored the missing UpperFilters entry manually and told me afterwards that this fixed the problem.

What does the UpperFilters entry look like?

I found this Acronis support article when I did a quick search on the Internet. It deals with a backup problem caused by a missing volsnap entry in the UpperFilters value. It describes how the value in UpperFilters should look in Acronis True Image 2020.

(Source: Acronis, Click to zoom)

The three entries must exist in the REG_MULTI_SZ value UpperFilters as shown in the screenshot above:

klbackupdisk
volsnap
fltsrv

After that you should be able to create again restore points in Windows 10. Thanks to Gerhard for the tip.

Similar articles:
Acronis True Image is loosing settings since Oct. 2019

[German]Microsoft blocks the upgrade to Windows 10 version 1903 and Windows 10 version 1909 if the system has older versions of Avast and AVG antivirus software installed.

When upgrading a Windows 10 system to the new version 1903 (May 2019 Update) or version 1909 (November 2019 Update), there may be several issues. Microsoft will then set an upgrade stopper for known issues. Microsoft maintains a list of known issues for Windows 10 (V1809 to 1909) which is available here.

Avast/AVG as Upgrade Blocker

On the status page, Microsoft has now made added some entries for Windows 10 Version 1903 and Windows 10 Version 1909 as of November 22, 2019 for systems with Avast/AVG.

Issues with some older versions of Avast and AVG anti-virus products

Microsoft and Avast has identified compatibility issues with some versions of Avast Antivirus and AVG Antivirus. Any application from Avast or AVG that contains Antivirus version 19.5.4444.567 or earlier is affected.

As a precaution, Microsoft has stopped the delivery of feature updates for Windows 10 version 1903 and Windows 10 version 1909 if the affected antivirus version of Avast and AVG is found there. Affected:

• Client: Windows 10, Version 1909; Windows 10, Version 1903
• Server: Windows Server, Version 1909; Windows Server, Version 1903

As a workaround, Microsoft recommends that you download and install an updated version of the Avast or AVG application before updating to Windows 10, version 1903 or Windows 10, version 1909. Instructions for Avast and AVG customers can be found in the following support articles:

• Avast support KB article
• AVG support KB artikle

Microsoft does not recommend attempting a manual update via the Update Now button or using the Media Creation Tool until a new version of Avast or AVG application has been installed. Then the feature update for Windows 10 version 1903 or Windows 10 version 1909 should be offered automatically.  (via)

Similar articles:
Windows 10 V1903: Known Issues – Part 1
Windows 10 V1903: Known Issues – Part 2

[German]Users of the Windows 10 November 2019 Update (Version 1909) complain about issues with Windows Explorer. There are freezes in Search and also malfunctions in the file manger.

Woody Leonhard has addressed some issues within this post, and MS Power User has this article dealing with issues. Blog readers also report comments that continue to report problems with the start menu or search.  In addition, a blog reader pointed out another annoyance with the Explorer on the weekend.

Start menu still broken

The issues in start menu and desktop search caused in Windows 10 Version 1903 with the update KB4515384 of September 10, 2019 are still plaguing some users (see this German comment). An upgrade from Windows 10 version 1903 to 1909 does not always fix the issues, as some user complains within this German comment. On the other hand, some German users reports that upgrading Windows 10 to version 1909 fixed the issue. This German user reports new issues, a left click on the start menu does not work anymore.

Search causes issues

A user at askwoody.com reports,  that the text in the search field is so small that it cannot be read. An entry in the Microsoft Answers forum reports a bug caused by Enablement Update KB4517245. KB4517245 upgrades Windows 10 version from 1903 to 1909. After this update, the copy & paste in search box ist broken.

BUG in feature update to windows 10 version 1909 via enablement package (KB4517245)

Hello, I’ve tested in two different machines and confirmed that after the “feature update to windows 10 version 1909 via enablement package (KB4517245)” it’s no longer possible to copy-paste to the search box present in folders (upper right corner) using the mouse, the right click is completely disabled.

For now I’ve removed the (KB4517245)…

I have the KB4524570 CU Windows 10 v1903 build 18362.476 the problem only happens after the installation of the (KB4517245). With the build 18362.476 everything works perfect.

This has to be a windows bug.

A right click is also deactivated. In the same thread, a user describes a stutter when searching Windows on the desktop. Several users confirm a freeze during the search.

Woody Leonhard has also included a guest article on ‘Solving search problems’ in a news letter. I don’t know if this will help.

The changed search function

German blog reader Stefan contacted me by mail on Sunday and pointed out the problems. He wrote:

Microsoft has once again annoyed many users because the search function in the File Explorer has been changed since V1909, and this “feature” can not be easily disabled or undone. It would be better if Microsoft would allow the users to decide against such a serious change, i.e. to make the feature optional.

Then he mentioned the MS answers forum entry dealing with search issues; I’ve mentioned above. I found his following hint interesting:

Since I also used the search function intensively so far, and I found this as it was before V1909 also better (the search starts already during the text input, is indexed one has immediately the search result), I am also disappointed about the forced change.

You can deactivate the new search function for a while with mach2, but Windows V1909 decides to activate the new search function again after a few days (probably by one of the many tasks in task planning).

Stefan refers to this article at German deskmodder.de who describe the tool Mach2 for deactivating the new search (discussion on MyDigital-Life). Since Windows 10 V1909 resets the search modified by Mach2 to the new functionality, Stefan solved it by running gpedit and executing a batch file with the mach2 command on shutdown. At this point thanks for the hint – maybe it will help someone.

Similar articles:
Windows 10 19H2: What could change
Windows 10 V1909 come end of October 2019 at the earliest
Windows 10 V1909: ISOs in VS subscription available
Windows 10 V1909: Build 18362.10024 in Slow Ring
Windows 10 V1909 in Release Preview Ring
Windows 10 V1909: Release on November 12, 2019?
Windows 10 V1909 is called November 2019 Update
Windows 10 V1909 released, how to get this update?
Windows 10 V1909: Available via WSUS and Update Assistant
Windows 10 V1909: Missing local user account during setup
Windows 10 V1909: Strange Update Status …. Bits jammed?
Windows 10 V1909: Administrative Templates (.admx)
Windows 10: Fixes for October 2019 (start menu) issues

[German]Security researchers from Microsoft have found that more than 80,000 computers have been infected by a malware called Dexphot. The malware is currently being used for crypto mining.

It has been running since 2018, with a peak of 80,000 infections in June. I came across the information about the following tweet.

Microsoft says new Dexphot malware infected more than 80,000 computers

> delivered via ICLoader
> used for cryptomining
> peaked in June at 80k infections
> used fileless execution, LOLbins, polymorphism, and redundant boot persistence mechanismshttps://t.co/vzsplOiW3g pic.twitter.com/GKgVqsodYu

— Catalin Cimpanu (@campuscodi) November 26, 2019

First noticed in October 2018

Microsoft has published the details in this blog post. The malware was noticed in October 2018 when Microsoft’s polymorphic outbreak monitoring system recorded a large increase in reports. This suggests that a large-scale malware campaign was developing.

Microsoft’s security team then watched the new malware attempt to infiltrate files that changed every 20-30 minutes on thousands of devices. The malware was then named “Dexphot” by Microsoft. 

Tricky infection methods

The Dexphot attack used a variety of sophisticated methods to bypass security solutions. There are different levels of code obfuscation, encryption, and the use of random filenames to hide the installation process.

Dexphot uses file-less techniques to execute malicious code in memory, leaving only a few traces that can be used for forensics. The malicious code has hijacked legitimate system processes to camouflage malicious activity. If Dexphot is not stopped during the infection phase, a crypto-miner will eventually run on the device. Monitoring services set up by the malware and scheduled tasks trigger a re-infection as soon as an attempt is made to remove the malware.

Microsoft Defender ATP blocks Dexphot 

In most cases, Microsoft Defender Advanced Threat Protection detection modules blocked Dexphot before execution. If that failed, behavior-based machine learning models provided protection. Given the persistence mechanisms of the threat, the polymorphism, and the use of file-less techniques, behavioral detection, according to Microsoft, was an important part of the comprehensive protection against this malware and other threats that exhibit similar malicious behavior.

According to this Microsoft page, Windows Defender under Windows 8.1 and Windows 10 also detects this malware as Trojan:Win32/Dexphot. Due to the detection capabilities, the infection rate is now greatly reduced. Details can be found in this Microsoft article.

[German]Another addendum to fixed issues in Windows 10 version 1903/1909, which led to upgrade blockades. Microsoft has fixed issues with some Realtek Bluetooth drivers, and unstable WiFi connections in Qualcomm drivers, and an audio driver bug has also been fixed.

When upgrading a Windows 10 system to the new version 1903 (May 2019 update) or version 1909 (November 2019 update), there may be several issues. Microsoft will then set an upgrade stopper for known problems. Microsoft maintains a list of known issues for Windows 10 (V1809 to 1909), which can be found here.  

Realtek Bluetooth driver issue fixed

Since May 2019 there have been problems with Bluetooth adapters from Realtek in Windows 10 Version 1903. Windows could no longer connect to the adapters. Microsoft blamed update KB4505057.

Unable to discover or connect to Bluetooth devices using some Realtek adapters

Microsoft has identified compatibility issues with some driver versions for Bluetooth radios made by Realtek. To safeguard your update experience, we have applied a compatibility hold on devices with affected driver versions for Realtek Bluetooth radios from being offered Windows 10, version 1903 or Windows Server, version 1903 until the driver has been updated.

The issue affected Windows 10 version 1903 and also version 1909, as well as the server variants. Microsoft states as of November 15, 2019 that this issue has been resolved with an updated driver for the affected Realtek Bluetooth adapter. The upgrade blocker for Windows 10 versions 1903 and 1909 has been removed.

Qualcom WiFi intermitted connection failures fixed

There was also the problem that users got older devices WLAN problems due to an outdated Qualcomm driver causing the loss of Wi-Fi connectivity. Affected were Windows 10 versions 1903 and 1909.

Microsoft states that this issue has been resolved with an updated Qualcomm Wifi driver. An updated Wi-Fi driver should be available from the device manufacturer (OEM). The upgrade blocker was removed on November 22, 2019.

Intel Audio intcdaud.sys Notification

Microsoft and Intel had already identified a problem with a number of Intel display audio device drivers in May 2019. This problem resulted in increased battery power consumption. Microsoft had stopped an upgrade for affected devices. Users attempting to upgrade to Windows 10, version 1903, received an intcdaud.sys notification if the affected Intel Audio Display device driver (intcdaud.sys, versions 10.25.0.3 to 10.25.0.8) was installed on the computer. The upgrade stopper also applied to Windows 10 version 1809..

Microsoft states that this issue was resolved as of November 12, 2019 with an updated Windows driver. The upgrade blockade has therefore been removed. If you still have upgrade problems, you should request a new driver from the OEM.

Similar articles
Windows 10 V1903: Known Issues – Part 1
Windows 10 V1903: Known Issues – Part 2
Windows 10 V1909: Issues with Explorer

[German]Today I want to bring up again another issue regarding the update behavior of Windows Server 2012 (default, not R2). Some machines running Windows Server 2012 have been in a pending update loop since early November 2019.

An old blog post from November 2019

I had already addressed the topic after a reader’s tip in the blog post Pending Pending Update Issue with Windows Server 2012 Standard at the beginning of November 2019. The problem: After installing the updates, some Windows Server 2012 goes into a restart loop, where the update process shows the status “Pending restart”. This status is not vanishing, i.e. the updates are installed repeatedly or retain the status “Pending restart” even after a restart.

(Click to zoom)

In the article, the blog reader had suspected that the “Desktop Experience” feature might be involved in this problem.

Restart loops for Windows Server 2012

In Microsoft’s Technet Forum there is now this thread in which a person affected describes his observation. 

Windows Server 2012 stuck in reboot loop “Configuring Updates: Stage 2 of 4

After installing November monthly updates from WSUS server, about 80% of 2012 Servers stuck in loop.

Server (VMware VM) launches a stage 2 of 4 again, then it goes shutdown of services and reboot.

All Servers restored from backup. Any updates tried to install cause loop.

Previous monthly updates uninstalling cause loop. Renaming of SoftwareDistribution, rescanning of updates and installing cause loop.

Last monthly installation has been made without any problems on all Servers.

All updates show the same behavior on the affected servers that the update cannot be completed successfully. Currently another administrator has posted this comment in the blog. He has this on about 20 machines running Windows Server 2012 (partly virtualized). Microsoft’s advice to perform an in-place upgrade for repair installation is not helpful. Programs and data are lost.

Meanwhile, a reader of my blog has referred to this article, where the problem is also described. A few days ago Woody Leonhard also posted this article on askwoody.com. It also describes a reboot loop on Windows Server 2012 following the installation of the Servicing Stack Update (KB4523208). The article goes back to this report by an administrator. He observed the mentioned restart loop on different Windows Server 2012 systems with SSU KB4523208 installed. However, only 6 of 75 servers were affected (bar metal and virtual servers).

Solution: Booting in Safe Mode

Within this post, the person concerned writes that he was able to solve the problem by booting in the safe mode. In Safe Mode, the restart loop was interrupted and the update was successfully installed. Using the safe mode to fix the restart loop is also mentioned as a solution in the Technet forum and in this article.

In safe mode, only basic Windows functions with a limited set of files and drivers are executed. Safe mode is described in this Microsoft document.

[German]On 26.11.2019 Microsoft released the Windows 10 Insider Preview Build 19033 (20H1) in Fast Ring as well as in Slow Ring for insiders. The development branch 20H1 will end in spring 2020 as the new Windows 10 version 2004.

The announcement of the new Insider Preview took place in the Windows Blog. With this build some things are changing again.  Windows Blog.

Fast Ring to get new development builds

After the 20H1 is nearing completion and the watermark of a previous build has been removed a few days ago, Microsoft will soon release new builds from the development department in Fast Ring. This means that Microsoft will soon be releasing builds from the RS_PRERELEASE development branch in the Fast Ring Insider Preview (currently only builds from the VB_RELEASE branch are available there). This also means that the desktop watermark will be returned with these builds. If you want to stay on Windows 10 20H1, check the Windows Insider settings and switch to the Slow Ring.

20H1 becomes Windows 10 Version 2004

This build of Windows 10 is released as version 2004. In the Windows Blog Microsoft explains the reason why the development branch 20H1 will be released in spring 2020 as Windows 10 version 2004. The version number 2004 was chosen because the version 2003 for this Windows 10 version could lead to confusion with the long-expired Windows Server 2003.

Windows 10 20H1 is finished

In Windows Blog Brandon LeBlanc explains that the watermark has been removed from this Windows Insider Preview (this was already the case with the predecessor). According to LeBlanc, this means that the development of this Windows 10 version has been completed. New insider builds are for troubleshooting purposes only. This confirms what I published at the end of October 2019 in the blog post “Does Microsoft change the Windows 10 RTM dates?” as a rumour: Microsoft wants to adjust the RTM release dates for Windows 10 builds in the future and complete feature updates at the end of the year (December) and in summer. However, it remains to be seen when the build will be generally released. 

What’s fixed in Preview Build 19033

It’s a bug fix release because Microsoft is working towards the final. Microsoft lists the following fixes:

• We fixed an issue that could result in Settings crashing for some users if you navigated to About when in Safe Mode.
• We fixed an issue resulting in some paired Bluetooth audio devices unexpectedly displaying with a cellphone icon in Bluetooth Settings.
• We fixed an issue where preferred Focus Assist automatic rules settings weren’t persisting upgrade.
• We fixed an issue where pressing the WIN + P keyboard shortcut twice in a row could result in ShellExperienceHost crashing.
• We fixed an issue that could result in the Start menu crashing on launch if a Windows update was pending restart.
• We fixed an issue where if you were using night light and weren’t already signed into a Microsoft Account, and subsequently attached your MSA, it would result in night light no longer working.
• We fixed an issue where if you quickly toggled Magnifier on and back off in Settings it would result in Magnifier.exe crashing.
• At this point, we’re removing the known issue that Settings still isn’t available outside of launching via the URI (ms-settings:) – so far we have not seen any reports from Insiders in the Slow ring that bypassed the impacted build range. If you are in the Fast ring, were on the impacted build range, and are one of the few still experiencing this issue, you will need to reset your PC. We appreciate your patience.
• We fixed an issue where you wouldn’t be able to type Chinese punctuation with the Pinyin IME after moving focus to and from a password field.
• Some users may have experienced error 80092004 when attempting to install build 19025.1052. This was isolated to that specific Cumulative Update and should not prevent installing build 19033.
• We have fixed an issue resulting in Start Code 38 with certain external USB 3.0 drives.

In this build there are still the following known issues:

• BattlEye and Microsoft have found incompatibility issues due to changes in the operating system between some Insider Preview builds and certain versions of BattlEye anti-cheat software. To safeguard Insiders who might have these versions installed on their PC, we have applied a compatibility hold on these devices from being offered affected builds of Windows Insider Preview. See this article for details.
• We’re looking into reports of the update process hanging for extended periods of time when attempting to install a new build.
• Some Insiders are reporting that after successfully installing printer drivers from the Optional Updates section, the same driver is still showing as available for install. We’re looking into the issue.
• We’re looking into reports of certain external USB 3.0 drives not responding with Start Code 10 after they’re attached.

[German]Microsoft has published a support bulletin that warns users of a new problem in Windows 10. Thunderbolt devices on the dock may stop working under certain circumstances. This affects all supported versions of Windows 10, but it occurs only in rare cases.

In the support article 4532436 (Devices connected through a Thunderbolt Dock stop working after the computer resumes from the S5 power state), Microsoft reveals details about the problem that may occur when waking up in S5 power mode. This affects the following constellation:

• A Computer running Windows 10, version 1909, 1903, 1809, 1803, or 1709 with Quick Start enabled.
• A Thunderbolt Dock has several devices connected to it, including a keyboard, mouse, and USB encryption sticks.

If the user then repeats the following steps, there is a 5% chance that the problem will occur.

1. Connect the Thunderbolt Dock to the computer so that the devices connected to the Thunderbolt Dock are enuerated.
2. Press the power button to set the system to a Soft Off (S5) power save state. 
3. After the screen is turned off, remove the Thunderbolt Dock. Then wait until the S5 process is complete.
4. Connect the Thunderbolt Dock, and then wait five seconds (until the Thunderbolt Dock stops displaying activity).

You can then turn on your computer and check. if the mouse, keyboard and USB stick are working. As mentioned above, in 5% of all cases, the devices on the Thunderbold dock may not work anymore. If the error occurs, the functionality of the devices cannot be restored by unplugging and plugging in the Thunderbolt dock. Instead, a restart of the computer is required. It’s a pretty exotic bug that only a few users are likely to encounter. But if the worst comes to the worst, you know what to do now. (via)

[German]Microsoft’s developers are cretins: They try to force people to give a user consent in a Windows 10 app, that the person concerned can never keep. Here are a few details.

It’s another case where Microsoft was caught with the fingers in the honey pot. It’s about a consent clause that the company knows the user will never be able to comply with. Chris Vickery noticed the whole thing and made it the subject of the following tweet.

This is what Microsoft is trying to pass off as “consent”.

It’s data laundering.

They should be ashamed (and fined) for doing this.
Microsoft knows 0% of users are likely to have consent of all people in a personal photo or video collection. pic.twitter.com/vfvMPIxtWy

— Chris Vickery (@VickerySec) November 28, 2019

Microsoft will show the user a page on which the user has to agree to comply with the following Microsoft condition the first time the photo app is opened.

By enabling the People setting, you repsent that you have all approriate contents from the people in your photos and videos.

The request for consent comes in photos, and the user should confirm when activating the people settings that he/she has the permission of all persons for storage, which can be seen in photos and videos.

It is clear that no user can guarantee this to Microsoft. Therefore, this condition is unenforceable and immoral. The mess is that the function is imposed on people. Chris Vickers calls this ‘data washing’ on the part of Microsoft and says that Redmond should be ashamed and punished for it. Because Microsoft knows that probably 0% of users have the consent of everyone in a personal photo or video collection to store the data.