Why am I seeing lots of Event ID 131 - DeviceSetupManager - Metadata staging failed errors?

Anonymous
2024-01-21T21:01:31+00:00

In Event Viewer I am seeing lots of errors and warning related to DeviceSetupManager problems. Judging from other questions, this is happening widely. I have been investigating this issue and believe I have some information which may be useful to Microsoft engineers. I have included a lot of data, so this is a long post.

First, here is a list of event entries which appear to all be related to this issue.

Event ID 200 - Warning - DeviceSetupManager - "A connection to the Windows Update service could not be established." 1/19/2024

Event ID 201 - Warning - DeviceSetupManager - "A connection to the Windows Metadata and Internet Services (WMIS) could not be established." 1/19/2024

Event ID 202 - Warning - DeviceSetupManager - "The Network List Manager reports no connectivity to the internet." 1/19/2024

Event ID 131 - Error - DeviceSetupManager - "Metadata staging failed, result=0x80072EFE for container '{936BBD1F-3F6B-11ED-882B-A4BB6DC6CC51}'" 1/19/2024

Event ID 131 - Error - DeviceSetupManager - "Metadata staging failed, result=0x80072F78 for container '{936BB9A3-3F6B-11ED-882B-806E6F6E6963}'" 1/19/2024

Event ID 131 - Error - DeviceSetupManager - "Metadata staging failed, result=0x80070490 for container '{003D2803-8A03-55FA-AACE-E0FC0D0FF0DB}'" 1/10/2024

There are a total of 198 of these events between 1/13/2024 and 1/19/2024 on my system.

I often see a cluster of 2-4 Event ID 202 items, separated by 1 millisecond or less. They nearly always occur during times

when I am actively using the system, and there was no noticeable loss of internet access as seen at the user level.

For event ID 131, using Microsoft's Err_6.4.5, here are possible meanings of the result codes:

0x80072EFE

C:\home\wjhb> err 0x80072EFE

for hex 0x80072efe / decimal -2147012866

WININET_E_CONNECTION_ABORTED winerror.h

The connection with the server was terminated abnormally

1 matches found for "0x80072EFE"

0x80072F78

C:\home\wjhb> err 0x80072F78

for hex 0x80072f78 / decimal -2147012744

WININET_E_INVALID_SERVER_RESPONSE winerror.h

The server returned an invalid or unrecognized response

1 matches found for "0x80072F78"

0x80070490

C:\home\wjhb> err 0x80070490

for hex 0x80070490 / decimal -2147023728

PEER_E_NOT_FOUND p2p.h

E_PROP_ID_UNSUPPORTED vfwmsgs.h

The specified property ID is not supported for the

specified property set.%0

WER_E_NOT_FOUND werapi.h

DRM_E_NOT_FOUND windowsplayready.h

as an HRESULT: Severity: FAILURE (1), FACILITY_WIN32 (0x7), Code 0x490

for hex 0x490 / decimal 1168

ERROR_NOT_FOUND winerror.h

Element not found.

5 matches found for "0x80070490"

These all look like HRESULT values:

0x80000000 = severity of warning (or failure if a COM HRESULT - see winerror.h)

0x00070000 = facility of Win32

0x00002efe, 0x00002f78, 0x00000490 are the facility's status codes

As such, the values in winerror.h are most likely to be the correct interpretation in this context.

In another question thread we learned that periodic checks for updated device metadata use values in the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata. The value of DeviceMetadataServiceURL under that key contains "http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409".  This URL produces a redirect URL of <http://dmd.metaservices.microsoft.com/metadata.svc>.

I used the wget program to see what happens when the base URL is accessed. Here is a series of examples.

C:\home\wjhb\tmp>wget -nd "http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409"

--2024-01-11 21:19:34-- http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409

Resolving go.microsoft.com... 69.192.109.165

Connecting to go.microsoft.com|69.192.109.165|:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily

Location: http://dmd.metaservices.microsoft.com/metadata.svc [following]

--2024-01-11 21:19:34-- http://dmd.metaservices.microsoft.com/metadata.svc

Resolving dmd.metaservices.microsoft.com... 138.91.171.81

Connecting to dmd.metaservices.microsoft.com|138.91.171.81|:80... failed: Connection timed out.

Retrying.

--2024-01-11 21:19:56-- (try: 2) http://dmd.metaservices.microsoft.com/metadata.svc

Connecting to dmd.metaservices.microsoft.com|138.91.171.81|:80... connected.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Retrying.

--2024-01-11 21:21:55-- (try: 3) http://dmd.metaservices.microsoft.com/metadata.svc

Connecting to dmd.metaservices.microsoft.com|138.91.171.81|:80... connected.

HTTP request sent, awaiting response... 502 Bad Gateway

2024-01-11 21:24:42 ERROR 502: Bad Gateway.

================================================================================

C:\home\wjhb\tmp>ucrt wget -nd "http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409" --2024-01-19 16:39:29-- http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409 Resolving go.microsoft.com (go.microsoft.com)... 2600:1402:b800:686::2c1a, 2600:1402:b800:682::2c1a, 23.54.202.151 Connecting to go.microsoft.com (go.microsoft.com)|2600:1402:b800:686::2c1a|:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://dmd.metaservices.microsoft.com/metadata.svc [following] --2024-01-19 16:39:29-- http://dmd.metaservices.microsoft.com/metadata.svc Resolving dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)... 138.91.171.81 Connecting to dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)|138.91.171.81|:80... failed: timed out. Retrying.

--2024-01-19 16:39:51-- (try: 2) http://dmd.metaservices.microsoft.com/metadata.svc Connecting to dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)|138.91.171.81|:80... failed: timed out. Retrying.

--2024-01-19 16:40:14-- (try: 3) http://dmd.metaservices.microsoft.com/metadata.svc Connecting to dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)|138.91.171.81|:80... failed: timed out. Retrying.

--2024-01-19 16:40:38-- (try: 4) http://dmd.metaservices.microsoft.com/metadata.svc Connecting to dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)|138.91.171.81|:80... connected. HTTP request sent, awaiting response... No data received. Retrying.

--2024-01-19 16:40:48-- (try: 5) http://dmd.metaservices.microsoft.com/metadata.svc Connecting to dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)|138.91.171.81|:80... connected. HTTP request sent, awaiting response... 502 Bad Gateway 2024-01-19 16:41:28 ERROR 502: Bad Gateway.

================================================================================

C:\home\wjhb\tmp>ucrt wget -nd "http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409" --2024-01-20 15:27:33-- http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409 Resolving go.microsoft.com (go.microsoft.com)... 2600:1402:3800:297::2c1a, 2600:1402:3800:2ad::2c1a, 23.36.70.120 Connecting to go.microsoft.com (go.microsoft.com)|2600:1402:3800:297::2c1a|:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://dmd.metaservices.microsoft.com/metadata.svc [following] --2024-01-20 15:27:33-- http://dmd.metaservices.microsoft.com/metadata.svc Resolving dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)... 20.231.121.79 Connecting to dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)|20.231.121.79|:80... failed: timed out. Retrying.

--2024-01-20 15:27:55-- (try: 2) http://dmd.metaservices.microsoft.com/metadata.svc Connecting to dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)|20.231.121.79|:80... failed: timed out. Retrying.

--2024-01-20 15:28:18-- (try: 3) http://dmd.metaservices.microsoft.com/metadata.svc Connecting to dmd.metaservices.microsoft.com (dmd.metaservices.microsoft.com)|20.231.121.79|:80... connected. HTTP request sent, awaiting response... 502 Bad Gateway 2024-01-20 15:28:20 ERROR 502: Bad Gateway.

================================================================================

So, in recent days, I see lots of connection attempts timing out, one case of "connection reset by peer", one case of "no data received" and many "502 Bad Gateway" errors.

Resolving dmd.metaservices.microsoft.com in DNS returns a series of IP addresses, no doubt for load balancing. Earlier today it started returning 52.142.223.178, which appears to be in Amsterdam. Each server is giving the same results, mostly "502 Bad Gateway" errors.

I believe my results readily tie back to the HRESULT values seen in the Event ID 131 entries, especially WININET_E_CONNECTION_ABORTED and WININET_E_INVALID_SERVER_RESPONSE.

Whatever program lurks behind <http://dmd.metaservices.microsoft.com/metadata.svc&gt; is obviously having a lot of problems. With tens (or hundreds) of millions of Windows systems doing periodic checks for updated device metadata, any slowdown or hang in the program behind the gateway will cause the server's listening socket's queue to fill up, probably resulting in those connection timeouts. The other results likely follow from the same problem. Whatever the cause, this has been happening for quite a while now so I hope that the underlying problem can be corrected, thus allowing checks for updated device metadata to succeed again.

In the interest of providing complete information about the Event Log entries, and at the risk of extending an already long post, here is one full example of each event ID, as provided by the Event Viewer. (Edit: this editor strips out all of the XML tags in the XML data part of the export, rendering it unusable. Therefore, I am only including the text part of the entries.)

================================================================================

Log Name: Microsoft-Windows-DeviceSetupManager/Admin

Source: Microsoft-Windows-DeviceSetupManager

Date: 1/19/2024 5:08:44 PM

Event ID: 131

Task Category: None

Level: Error

Keywords:

User: SYSTEM

Computer: D***MI

Description:

Metadata staging failed, result=0x80072EFE for container '{936BBD1F-3F6B-11ED-882B-A4BB6DC6CC51}'

===================================================================================================

Log Name: Microsoft-Windows-DeviceSetupManager/Admin

Source: Microsoft-Windows-DeviceSetupManager

Date: 1/19/2024 8:49:11 PM

Event ID: 131

Task Category: None

Level: Error

Keywords:

User: SYSTEM

Computer: D***6MI

Description:

Metadata staging failed, result=0x80072F78 for container '{00000000-0000-0000-FFFF-FFFFFFFFFFFF}'

===================================================================================================

Log Name: Microsoft-Windows-DeviceSetupManager/Admin

Source: Microsoft-Windows-DeviceSetupManager

Date: 1/10/2024 4:50:07 AM

Event ID: 131

Task Category: None

Level: Error

Keywords:

User: SYSTEM

Computer: DE***6MI

Description:

Metadata staging failed, result=0x80070490 for container '{003D2803-8A03-55FA-AACE-E0FC0D0FF0DB}'

===================================================================================================

Log Name: Microsoft-Windows-DeviceSetupManager/Admin

Source: Microsoft-Windows-DeviceSetupManager

Date: 1/19/2024 8:47:15 PM

Event ID: 200

Task Category: None

Level: Warning

Keywords:

User: SYSTEM

Computer: DE***MI

Description:

A connection to the Windows Update service could not be established.

===================================================================================================

Log Name: Microsoft-Windows-DeviceSetupManager/Admin

Source: Microsoft-Windows-DeviceSetupManager

Date: 1/19/2024 8:48:06 PM

Event ID: 201

Task Category: None

Level: Warning

Keywords:

User: SYSTEM

Computer: DES***6MI

Description:

A connection to the Windows Metadata and Internet Services (WMIS) could not be established.

===================================================================================================

Log Name: Microsoft-Windows-DeviceSetupManager/Admin

Source: Microsoft-Windows-DeviceSetupManager

Date: 1/19/2024 8:47:15 PM

Event ID: 202

Task Category: None

Level: Warning

Keywords:

User: SYSTEM

Computer: DE***6MI

Description:

The Network List Manager reports no connectivity to the internet.

===================================================================================================

Note: I am not aware that I am having any difficulties with internet connectivity. I believe the descriptions in the events are responding to various error codes and making an assumption about possible causes. Connection failures to Microsoft servers are generally expected to be due to network problems, not server problems, so this is perhaps an understandable way to summarize a variety of error codes.

Also, I recently ran DISM to look for corrupted system files and SFC to correct any problems. Neither tool found any issues. The above evidence clearly shows that the underlying problem is not on my system, but on the servers responding to the <http://dmd.metaservices.microsoft.com/metadata.svc&gt; URL.

Thoughts, ideas, suggestions gratefully accepted.

Windows for home | Windows 11 | Devices and drivers

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.

0 comments No comments
{count} votes
Accepted answer
  1. Anonymous
    2024-01-23T10:08:01+00:00

    Hi, William Bresler

    Welcome to the Microsoft Community.

    I have seen this problem reported by other members of the community and the reason for this error is the registry key: 
    
       HKLM/SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata\DeviceMetaDataServiceURL 
    
    Point to this URL: [http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409](http://go.microsoft.com/fwlink/?LinkID=252669&amp;clcid=0x409 "go.microsoft.com")  
    
    Then redirects to the following URL: [https://devicemetadataservice.trafficmanager.net/dms/metadata.svc](https://devicemetadataservice.trafficmanager.net/dms/metadata.svc "devicemetadataservice.trafficmanager.net") 
    
    The 2nd URL is broken. (as you guessed at the end of your post) 
    
    Here are two things you can try:
    
    1. Disable metadata staging:  
    
    • Windows Settings > System > About > Advanced System Settings > Select the Hardware tab > Click the Device Installation Settings button.
    • In the pop-up box that appears, you can change it from Yes (recommended) to No (device may not function as expected).
      1. Edit the registry:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-DeviceSetupManager/Admin "Enabled"=dword:00000000 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata

    "PreventDeviceMetadataFromNetwork"=dword:00000001

    This issue should be solved temporarily by the above method, if you want to completely solve this issue, it may require the development team to fix it, you can submit your ideas and suggestions through the [Feedback Hub](https://support.microsoft.com/en-in/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app "support.microsoft.com"), and the development team will regularly review submissions for ideas or fixes. Please share the feedback link here after submitting as it will allow others on the forum to vote for your submission, including me. More votes will lead to more visibility and higher priority to the development team. 
    

    Best Regards

    Martin | Microsoft Community Support Specialist

    109 people found this answer helpful.
    0 comments No comments

46 additional answers

Sort by: Most helpful
  1. Anonymous
    2024-01-23T20:59:42+00:00

    Thank you for this information. In the interest of avoiding all of these Event Log entries which, under the current circumstances, cannot be resolved, I will go ahead and make the indicated changes to my system. until such time as the supporting URL is repaired.

    Before I use the Feedback Hub to report this, I wanted to say that my experience with the redirect URL from "http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409" is a bit different.

    When I first began investigating this issue, I was using a version of wget that is available for the MSYS2 environment on Windows. (MSYS2 is derived from a lightly modified fork of the Cygwin Unix/Linux emulation DLL but is focused on providing tools to build native Windows versions of various open-source projects.) I was using the version of wget that runs in the Unix/Linux emulation environment, using bash as the shell running under mintty as the terminal emulator. I failed to surround the URL with single quotes which allowed bash to interpret some of the characters as special. In particular, '?' and '&'. The '&' terminates the command and causes it to be run as a background job. This means that the second query parameter in the URL was omitted but was instead interpreted as an assignment of a value to a shell variable. OOPS.

    The result of that is the following:

    C:\home\wjhb>ucrt wget -nd "http://go.microsoft.com/fwlink/?LinkID=252669"

    --2024-01-23 15:03:18-- http://go.microsoft.com/fwlink/?LinkID=252669 Resolving go.microsoft.com (go.microsoft.com)... 2600:1402:b800:686::2c1a, 2600:1402:b800:682::2c1a, 23.63.205.212

    Connecting to go.microsoft.com (go.microsoft.com)|2600:1402:b800:686::2c1a|:80... connected.

    HTTP request sent, awaiting response... 302 Moved Temporarily

    Location: http://devicemetadataservice.trafficmanager.net/dms/metadata.svc [following]

    --2024-01-23 15:03:18-- http://devicemetadataservice.trafficmanager.net/dms/metadata.svc Resolving devicemetadataservice.trafficmanager.net (devicemetadataservice.trafficmanager.net)... failed: No such host is known.

    wget: unable to resolve host address 'devicemetadataservice.trafficmanager.net'

    This matches your URL except that it uses HTTP rather than HTTPS. In this case, the domain of devicemetadataservice.trafficmanager.net does not even exist in DNS.

    C:\home\wjhb>nslookup devicemetadataservice.trafficmanager.net. Server: one.one.one.one Address: 2606:4700:4700::1111

    *** one.one.one.one can't find devicemetadataservice.trafficmanager.net.: Non-existent domain

    However, restoring the second query parameter yields a redirect URL of http://dmd.metaservices.microsoft.com/metadata.svc as seen in the various examples in my post above. It does exist in DNS but has the other problems I indicated.

    I have not yet worked out what clcid=0x409 means here. I can say that on my system I looked in the registry for all values containing "go.microsoft.com" and found two of them using clcid as a parameter: DeviceMetadataServiceURL under "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata" and RequestUrl under "HKLM\SOFTWARE\Microsoft\LexiconUpdate\loc_0804".

    So, is it possible that someone omitted the clcid parameter, as I accidentally did, while looking for the redirect URL?

    Anyway, thanks again for your reply. I'll post again with a link to my feedback request.

    8 people found this answer helpful.
    0 comments No comments
  2. Anonymous
    2024-01-26T02:05:09+00:00

    Hi, William Bresler

    I am very glad to receive your reply. I haven't seen you share the feedback link yet. By the way, if you are interested in the technical principles behind it and want to understand the meaning of the parameters, it is more suitable for publishing on Microsoft Learn, you can click "Ask a question", there are experts there to provide more professional answers and suggestions.
    
    Here is a [link](https://learn.microsoft.com/en-us/answers/ "learn.microsoft.com") to the forum where you can raise specific scenarios and share your idea to help solve the problem.
    

    Best Regards

    Martin | Microsoft Community Support Specialist

    2 people found this answer helpful.
    0 comments No comments
  3. Anonymous
    2024-04-12T06:47:09+00:00

    Hi,

    Piggybacking on this thread, this is happening more and more for me as well months after this report.

    373 events, ID 131 - DeviceSetupManager

    Every day several, looks like right after boot.

    Examples:

    Metadata staging failed, result=0x80070490 for container '{FF230B18-AC03-5A40-870E-3D9A4B6F5C78}'

    Metadata staging failed, result=0x80070490 for container '{D397268A-724C-B4EF-D641-C9234BA2948B}'

    Metadata staging failed, result=0x80070490 for container '{00000000-0000-0000-FFFF-FFFFFFFFFFFF}'

    12 people found this answer helpful.
    0 comments No comments
  4. Anonymous
    2024-04-14T22:28:06+00:00

    The problem indeed persists. Microsoft has made some changes, though, to a few things. A recent patch Tuesday update changed the registry values which control this function of Windows. The entry is HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata\DeviceMetadataServiceURL which previously had the data **http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409**but which is now, at least on my system, https://go.microsoft.com/fwlink/?LinkID=2257403&clcid=0x409.

    Note that it now uses a secure https connection rather than a plain http one, and the link ID has changed.

    Normally, the go.microsoft.com site is used translate a LinkID into an HTTP redirect response to the actual URL that will provide the data or function requested. You can see some of those in my earlier posts to this thread. Currently, and for the last two months or so, this is what I see happening:

    C:\home\wjhb>ucrt wget -nd "https://go.microsoft.com/fwlink/?LinkID=2257403&clcid=0x409"
    --2024-04-14 17:59:15--  https://go.microsoft.com/fwlink/?LinkID=2257403&clcid=0x409
    Resolving go.microsoft.com (go.microsoft.com)... 2600:1402:1400:7a0::2c1a, 2600:1402:1400:79f::2c1a, 2600:1402:1400:783::2c1a, ...
    Connecting to go.microsoft.com (go.microsoft.com)|2600:1402:1400:7a0::2c1a|:443... connected.
    HTTP request sent, awaiting response... 502 Bad Gateway
    2024-04-14 17:59:15 ERROR 502: Bad Gateway.
    

    As you can see, the new LinkID causes go.microsoft.com to immediately respond with a 502 Bad Gateway response. The previous redirection goes to a site that often causes connection attempts to fail, and, when they do succeed, there is a long delay before it too returns a 502 Bad Gateway error. So, the current situation is one where the connection attempts succeed, but the desired function is replaced with an immediate 502 error. This keep Windows client systems from hanging while waiting for a response, but still causes the Device Metadata lookups to fail and this causes all of the critical error entries in the Event Log.

    If you are comfortable making changes to the registry, the suggestions earlier in this thread do inhibit the lookups and so there won't be all of those error events. I did this on my system and did not observe any problems.

    I can also report that if one does a wider internet search for this problem one can see dozens of posts in various forums going back at least as far as 2014 and Windows 7. The registry entry was exactly the same, the DeviceMetadataServiceURL had the exact same LinkID and the Event IDs were the same. Whatever the reason for the current difficulty, it seems as though Microsoft has dealt with this issue intermittently for a long time.

    Back in January I did go to the Feedback Hub but I discovered that there were already hundreds of posts about this issue. Many of them had been grouped into collections so that a single response would suffice for all of them. Unfortunately, this hid the text of those posts so I could not tell whether I might be able to offer additional information or details. In the end I decided not to submit a new feedback but I did continue to monitor the issue. That is how I came to observe the changes described in this post.

    I am not sure how we can convince Microsoft to raise the priority of this issue. I would think that functions designed to keep Windows device drivers up to date would be pretty important. I hope this issue gets the attention it deserves soon.

    12 people found this answer helpful.
    0 comments No comments