Windows Server 2025 RDSH: Start menu search stays on "loading" indefinitely – SearchHost's WebView2 never navigates

Hi Kevin,

Thank you for the detailed description and for sharing the WPR findings. The comparison between a hanging and a working SearchHost instance is especially useful.

Based on the trace you described, the failing instance does not yet point to DNS or a general network outage. The WebView2 network service makes no DNS or TCP requests, which suggests that it may be stopping before it issues a network request. The fact that restarting SearchHost creates a new WebView2 instance that works points to an intermittent startup or initialization problem, but the trace as described does not identify the specific cause.

The WAM delays and AAD errors are worth recording, but since they also occur in the working instance, they do not currently distinguish the failure from a successful launch. The SearchHost restart is a useful temporary workaround and diagnostic clue; it does not, by itself, identify the root cause.

There was a separate RDS issue after the September update, which Microsoft lists as resolved by KB5129235 and later updates. Its documented symptoms included RDP failures and broader RDS unresponsiveness; that is not enough to confirm it is the same issue you are seeing. The October update includes fixes from that release. Windows Server 2025 known issues, KB5126646

next steps

1. Capture a WebView2-specific trace during the hang. Microsoft’s WebView2 diagnostics guidance recommends the WebView2_CPU.wprp profile for most investigations. It captures WebView2 events and CPU sampling, including process launch and navigation timing. In an elevated Command Prompt, the basic sequence is:

wpr -start WebView2_CPU.wprp -filemode

Reproduce the Start-menu hang, then stop the recording:

wpr -stop C:\Temp\WebView2-hang.etl "Start/Search hang"

Capture a second trace of a successful Start launch using the same profile and similar timing. If possible, record the SearchHost and WebView2 process IDs, the user session, and the time Start was opened. Stop the trace before terminating SearchHost, so the failing state is preserved. Keep the capture brief, and do not post raw ETL files publicly; they can contain sensitive information. WebView2 ETW tracing guidance, WebView2 performance guidance

1. Compare the failed and successful traces. The key question is whether the failing trace shows WebView2 receiving or starting a navigation. Compare the WebView2 process tree, launch times, command lines, user-data-folder paths, and navigation events. If there is no navigation event in the failing trace, that would help narrow the investigation to an earlier part of the SearchHost/WebView2 startup path.
2. Check whether the issue follows a user or a host. On a canary host, compare a fresh test profile with an affected profile, and compare the same user on another host if practical. Since you saw one occurrence in a plain RDP session with a local profile, repeat that comparison if the issue happens again. Please capture the affected profile’s details before resetting or recreating it.
3. Review logs and security controls at the failure time. Check the Application log and, where available, the Search and AppModel Runtime logs. Also check AppLocker or Code Integrity, Defender, and third-party security or monitoring products for blocks or errors involving SearchHost or WebView2. Since you have seen the issue outside Citrix, Citrix should not be assumed to be the cause; still, comparing a canary with and without relevant Citrix or security components may help isolate a factor. Avoid disabling security controls across production hosts as a first test.

WebView2 supports browser flags such as --log-net-log, but these flags normally need to be supplied by the application hosting WebView2 or through supported diagnostic overrides. SearchHost does not provide an administrator-facing setting for its WebView2 arguments, so it is not safe to assume a flag will be applied to this instance. Microsoft also cautions against using these flags in production applications. For this multi-session environment, I would start with the WebView2 ETW profile rather than applying a machine-wide logging override. WebView2 browser flags

KB5134137, released on October 26, is an out-of-band update whose published purpose is to provide an updated trusted-root certificate payload for certain devices. Its notes do not describe a Start/Search fix, so I would not treat it as a workaround for this symptom. KB5134137

The timing after the October update is worth investigating, but it does not yet establish that the update caused the issue. If you can reproduce it reliably, a comparison using cloned images—one with the affected update baseline and one with a different supported baseline—would be more informative than changing several components on the production farm at once.

Thank you again for providing such a thorough trace and environment summary. If you can share the key differences between the successful and failing WebView2 ETW timelines, along with whether the issue follows a particular user or host, that should help narrow down the next step.

Hi Kevin,

Thank you for the detailed description and for sharing the WPR findings. The comparison between a hanging and a working SearchHost instance is especially useful.

Based on the trace you described, the failing instance does not yet point to DNS or a general network outage. The WebView2 network service makes no DNS or TCP requests, which suggests that it may be stopping before it issues a network request. The fact that restarting SearchHost creates a new WebView2 instance that works points to an intermittent startup or initialization problem, but the trace as described does not identify the specific cause.

The WAM delays and AAD errors are worth recording, but since they also occur in the working instance, they do not currently distinguish the failure from a successful launch. The SearchHost restart is a useful temporary workaround and diagnostic clue; it does not, by itself, identify the root cause.

There was a separate RDS issue after the September update, which Microsoft lists as resolved by KB5129235 and later updates. Its documented symptoms included RDP failures and broader RDS unresponsiveness; that is not enough to confirm it is the same issue you are seeing. The October update includes fixes from that release. Windows Server 2025 known issues, KB5126646

next steps

1. Capture a WebView2-specific trace during the hang. Microsoft’s WebView2 diagnostics guidance recommends the WebView2_CPU.wprp profile for most investigations. It captures WebView2 events and CPU sampling, including process launch and navigation timing. In an elevated Command Prompt, the basic sequence is:

wpr -start WebView2_CPU.wprp -filemode

Reproduce the Start-menu hang, then stop the recording:

wpr -stop C:\Temp\WebView2-hang.etl "Start/Search hang"

Capture a second trace of a successful Start launch using the same profile and similar timing. If possible, record the SearchHost and WebView2 process IDs, the user session, and the time Start was opened. Stop the trace before terminating SearchHost, so the failing state is preserved. Keep the capture brief, and do not post raw ETL files publicly; they can contain sensitive information. WebView2 ETW tracing guidance, WebView2 performance guidance

1. Compare the failed and successful traces. The key question is whether the failing trace shows WebView2 receiving or starting a navigation. Compare the WebView2 process tree, launch times, command lines, user-data-folder paths, and navigation events. If there is no navigation event in the failing trace, that would help narrow the investigation to an earlier part of the SearchHost/WebView2 startup path.
2. Check whether the issue follows a user or a host. On a canary host, compare a fresh test profile with an affected profile, and compare the same user on another host if practical. Since you saw one occurrence in a plain RDP session with a local profile, repeat that comparison if the issue happens again. Please capture the affected profile’s details before resetting or recreating it.
3. Review logs and security controls at the failure time. Check the Application log and, where available, the Search and AppModel Runtime logs. Also check AppLocker or Code Integrity, Defender, and third-party security or monitoring products for blocks or errors involving SearchHost or WebView2. Since you have seen the issue outside Citrix, Citrix should not be assumed to be the cause; still, comparing a canary with and without relevant Citrix or security components may help isolate a factor. Avoid disabling security controls across production hosts as a first test.

WebView2 supports browser flags such as --log-net-log, but these flags normally need to be supplied by the application hosting WebView2 or through supported diagnostic overrides. SearchHost does not provide an administrator-facing setting for its WebView2 arguments, so it is not safe to assume a flag will be applied to this instance. Microsoft also cautions against using these flags in production applications. For this multi-session environment, I would start with the WebView2 ETW profile rather than applying a machine-wide logging override. WebView2 browser flags

KB5134137, released on October 26, is an out-of-band update whose published purpose is to provide an updated trusted-root certificate payload for certain devices. Its notes do not describe a Start/Search fix, so I would not treat it as a workaround for this symptom. KB5134137

The timing after the October update is worth investigating, but it does not yet establish that the update caused the issue. If you can reproduce it reliably, a comparison using cloned images—one with the affected update baseline and one with a different supported baseline—would be more informative than changing several components on the production farm at once.

Thank you again for providing such a thorough trace and environment summary. If you can share the key differences between the successful and failing WebView2 ETW timelines, along with whether the issue follows a particular user or host, that should help narrow down the next step.

Hello,

Thank you for the detailed follow-up and for capturing the kernel stacks and live dump. These findings narrow the issue considerably. In the captured hangs, the WebView2 child processes remain blocked in FSCTL_PIPE_WAIT requests queued in NPFS, while SearchHost and the browser process continue running. The requests remain pending until the app job is terminated.

This points to the named-pipe wait/listen path as the place where the stall occurs. A race involving simultaneous child-process startup and the LOCAL\ alias is a plausible explanation, but the dump alone does not prove that the alias is responsible or that this is a confirmed NPFS defect. I can’t confirm a publicly acknowledged Windows Server 2025 issue matching this exact behavior.

For a private investigation, please don’t attach the 8 GB kernel dump or user-mode dumps to this public thread. A kernel dump may contain memory from other active sessions. I’m not aware of a supported private dump-sharing channel outside a support request. Microsoft’s Support for Business portal documents a pay-per-incident option for on-premises products where available. Once a case is open, ask the support contact for the approved secure upload method; Microsoft documents a case-specific Secure File Exchange workspace.

I would not recommend trying to disable Crashpad or change SearchHost’s WebView2 configuration. The documented crash-reporting control is an API for the application hosting WebView2; it does not provide an administrator setting for changing the in-box SearchHost configuration, and it is not documented as changing this named-pipe initialization path. WebView2 crash-reporting documentation

One detail to reconcile for the support case: an earlier post lists build 26100.33650, while this kernel dump is from 26100.33648. Please include the exact OS build and update level for each affected host, along with the WebView2 version, ETL trace, and relevant dumps. Keep the public thread to a sanitized summary.

Thanks again for documenting the issue so thoroughly. The kernel evidence gives the support team a much more specific starting point for investigation.

Hi,

Thank you for collecting the additional traces and dumps. The repeated results across users and hosts make this a much stronger finding. The stack indicates that the WebView2 network-service process is waiting in Crashpad initialization before it finishes starting, which explains why navigation does not proceed. This is a more relevant lead than DNS or the page content.

Crashpad’s upstream Windows code uses WaitNamedPipe with an infinite timeout after CreateFile returns ERROR_PIPE_BUSY. Its server implementation also normally creates two pipe instances, so seeing two listener threads is not, by itself, evidence of a fault. The key question is whether those listeners serve the exact pipe endpoint requested by the stuck child processes. If they do, but those clients remain blocked, that would be unexpected and worth engineering investigation. Crashpad client code, Crashpad server code, Microsoft WaitNamedPipe documentation

I can’t confirm a published Windows Server 2025 issue matching this exact Crashpad pipe behavior. The upstream implementation explains how an indefinite wait can occur, but it does not establish that this is a known Server 2025 defect.

The next useful comparison is to map each stuck child’s EDGE_CRASHPAD_PIPE_NAME to the full pipe name and process ID of the handler that owns the listener threads. Please also capture the SearchHost and WebView2 browser-process dumps during the same confirmed hang, as planned. Keep one successful and one failed trace for comparison. These additional captures would strengthen the investigation, but you already have enough evidence to report the issue now.

For a private Microsoft investigation, an existing support agreement is not the only option. The Support for Business portal may offer a Pay Per Incident purchase for an on-premises product. Microsoft’s instructions say this requires a Microsoft account and credit card, and the option may depend on product and region. Microsoft: creating on-premises support incidents

You can also submit a sanitized report to the MicrosoftEdge/WebView2Feedback repository. It is a public repository, so don’t attach raw ETL files or dumps there. You can ask the maintainers whether they can provide an approved private transfer method.

I don’t know of a supported administrator-level setting to disable Crashpad specifically for the WebView2 instance hosted by SearchHost. The documented crash-reporting option is configured by the application when it creates the WebView2 environment; it is not a SearchHost administrator setting and does not show that Crashpad initialization would be skipped. WebView2 data and privacy documentation

Thank you again for the careful investigation. The exact client-to-handler pipe mapping, together with the planned SearchHost and browser-process dumps, should help make the escalation much more actionable.

Hi Kevin,

Thank you for the detailed follow-up and for correcting the earlier DNS interpretation. Your trace gives us a much narrower point to investigate.

The navigation starts, and WebView2 records OnReceiveResponse, but no document commit is observed afterward. That places the stall somewhere between the response event and the navigation commit; it does not yet identify the component responsible. Also, OnReceiveResponse alone may not prove that the entire response body was delivered. Chromium’s navigation documentation describes additional response processing, renderer selection, and a commit message/acknowledgment before a document is committed. Chromium: Life of a Navigation

Your virtual-host finding also makes DNS/NXDOMAIN an unlikely lead here. WebView2 supports mapping an HTTP or HTTPS virtual host name to local content on disk, so a URL that looks like a network address can be served locally. Microsoft: Using local content in WebView2 apps

For the next capture, I would use Microsoft’s WebView2_CPU.wprp profile on one affected host during a confirmed hang. It adds system process/thread and CPU events, including sampled CPU, context-switch and ready-thread stacks, alongside WebView2, Edge, and V8 events. That should provide more useful context than adding more keywords to the WebView2 provider-only ring buffer. Start the capture shortly before reproducing the issue and stop it promptly once the hang is recorded. WebView2 ETW instructions, WebView2_CPU.wprp profile

In that trace, the most useful comparisons would be:

• Whether a response-stage WillProcessResponse throttle runs and proceeds. The WillStartRequest results you already captured cover an earlier stage.
• The response status, content type, and any response-completion/body events for 2.html.
• Whether the browser selects a renderer and sends a commit request, and whether the renderer responds.
• The browser and renderer thread stacks and scheduling state during the interval where the hang persists.

If the hang is still present after saving the ETL, please capture a memory dump of the matching SearchHost and WebView2 browser process before restarting them. The WebView2 diagnostics guidance recommends dumps for unresponsive processes. These traces and dumps may contain user or session data, so please don’t post the raw files publicly; share them through a private Microsoft support case if one is opened. WebView2 diagnostics: memory dumps

The reproduction on runtime 152.0.4191.53 shows that updating from 151 did not resolve the issue; it does not, by itself, prove whether the runtime or the SearchHost/WebView2 integration is at fault. Likewise, the third trace is useful, but please confirm whether that user actually saw Start remain on “loading” and whether restarting SearchHost cleared it. That will tell us whether the same trace sequence reliably corresponds to the visible hang.

I can’t confirm a published known issue for this exact SearchHost/WebView2 commit stall. Given that you can capture it across users and hosts, a Microsoft support case with the ETL and dumps shared privately would be a reasonable next step if the short WPR capture does not reveal where the commit path is waiting.

Thanks again for gathering such a useful comparison and sharing the results.

Hi Kevin,

welcome to Microsoft Q&A.

I am checking your question and will be back within some minutes.