Azure Migrate Physical Server Discovery - ServerDiscoveryService.exe Crash Bug 2.0

M 5 Reputation points

Im facing the exact same issue as https://learn.microsoft.com/en-us/answers/questions/5747176/azure-migrate-physical-server-discovery-serverdisc

Is there any update regarding this? Workaround?

0 comments No comments
Sign in to comment

3 answers

  1. Siva shunmugam Nadessin 10,895 Reputation points • Microsoft External Staff • Moderator

    Hello M,

    Thank you for reaching out to the Microsoft Q&A forum. 

    When investigated it looks like you’re hitting the ServerDiscoveryService.exe crash in the Azure Migrate appliance when doing physical‐server discovery. Unfortunately, there’s no public “patch” for the 2.0 bug right now, but here are a few things you can try in the meantime, plus some questions that will help narrow down what’s happening:

    What to try first

    1. Verify appliance prerequisites
      • Make sure your appliance VM meets the physical server appliance requirements (Windows Server version, RAM/CPU, disk space) and can reach all required URLs (incl. the discovery endpoints).
      • If you’re behind a proxy or firewall, double-check that you’ve allow-listed the full list of Azure Migrate URLs from the support matrix.
    2. Re-run the appliance installer script
      • On the appliance host, rerun AzureMigrateInstaller.ps1 to clean up and redeploy the appliance bits. This will refresh the ServerDiscoveryService components.
    3. Update to the latest appliance bits
      • If you haven’t already, download and install the latest Azure Migrate appliance script/agent from the portal. We occasionally bundle hot-fixes in the “auto-update” channel.
    4. Collect logs & event dumps
      • Grab the ServerDiscoveryService crash dump and logs from %ProgramData%\Microsoft Azure\Logs\ServerDiscoveryService\
      • Check Windows Event Viewer under “Application” for the crash entry and note the faulting module
    5. Fallback to agent-based discovery for affected servers
      • If it’s only a handful of servers, you can install the Mobility Service directly on each machine and let Azure Site Recovery do “agent-based” discovery instead of agentless appliance discovery.

    Key follow-up questions

    1. Which exact appliance version & build are you running? (you can get this from the appliance config manager footer)
    2. What OS version is the appliance on (e.g. Windows Server 2016/2019)?
    3. Are there any proxy/firewall logs showing blocked calls to the discovery endpoints?
    4. Can you share the faulting module name and exception code from Event Viewer?
    5. Does the crash happen immediately on start or only after a certain number of servers are processed?

    Once we have that info (especially the crash dump and version details), we can drill into whether this is environmental or a reproducible bug that needs escalation.

    References

    • Support matrix for physical server discovery and assessment – prerequisites and limits https://docs.microsoft.com/azure/migrate/migrate-support-matrix-physical

    • Run the Azure Migrate appliance installer script (re-deploy/repair) https://docs.microsoft.com/azure/migrate/how-to-set-up-appliance-physical

    • Troubleshoot Azure Migrate appliance (network, prerequisites checks) https://docs.microsoft.com/azure/migrate/troubleshoot-general

    • Migrate machines as physical servers to Azure (agent-based fallback) https://docs.microsoft.com/azure/migrate/tutorial-migrate-physical-virtual-machines

    Hope this helps!! – let me know the answers to the questions above and any logs you can share, and we’ll get you a more concrete workaround.

    1. Siva shunmugam Nadessin 10,895 Reputation points • Microsoft External Staff • Moderator

      Hello M,

      Just checking in to see if the solution shared above help you to resolve your issue. please reach out to us If you have any further questions.

      Thanks

    Sign in to comment
  2. Alex Burlachenko 22,120 Reputation points • MVP • Volunteer Moderator

    M hi and thx for join us at Q&A portal,

    yeah this is usually not Azure side, its local agent crash (deps/env)

    do this check logs: C:\ProgramData\Microsoft Azure Migrate\Logs\

    fix common causes like install latest .NET runtime + VC++ 2015–2022 repair WMI

    winmgmt /verifyrepository winmgmt /salvagerepository

    then clean reinstall, uninstall > delete C:\ProgramData\Microsoft Azure Migrate\ C:\Program Files\Microsoft Azure Migrate\ reboot > install latest appliance

    disable AV temporarily and ensure outbound 443 works (no broken proxy), if still crashing so capture dump

    procdump -e -ma ServerDiscoveryService.exe

    deps/WMI/corrupt install, fix + clean reinstall

    rgds,

    Alex

    1. M 5 Reputation points

      Hi Alex, thanks for your response.

      I checked everything and started a new Migrate Project, but still same issue with ServerDiscoveryService.exe which is crashing.

      I created the crashdump and zipped it, how can i send this to you? Max file size is 3MB here :). I'll add a screenshot with some errors for now which occured during the crash. 👁 User's image

    2. Alex Burlachenko 22,120 Reputation points • MVP • Volunteer Moderator

      hi, thx for checking and for the dump

      u cant upload crash dumps here and you should not share them publicly anyway (they may contain sensitive data). best way is to open a Microsoft support ticket via Azure portal (Help + Support > Technical > Azure Migrate) and attach dump + logs from C:\ProgramData\Microsoft Azure Migrate\Logs\ + timestamp of crash. this will go directly to product team. Based on your screenshot this is not a config issue, its native crash (C0000005 ACCESS_VIOLATION). that usually means dependency or external interference, not Azure backend.

      AV/EDR temporarily disable or add exclusion for ServerDiscoveryService.exe (very common root cause)

      VC++ runtime (repair/reinstall 2015–2022)

      .NET runtime actually used by service

      WMI health (winmgmt /verifyrepository)

      check if any proxy/SSL inspection is in place

      if u want quicker isolation, run procdump -e -ma -w ServerDiscoveryService.exe and check which module throws the exception (DLL name). that usually immediately points to root cause. honestly, repeated ACCESS_VIOLATION like this almost always ends up being AV/EDR or broken runtime, not Azure Migrate itself.
      rgds,

      Alex

      &pls if it helps accept my answer and mark it as an answer
    Sign in to comment

  3. AI answer

    The provided information doesn't include any update or specific workaround for a ServerDiscoveryService.exe crash bug in Azure Migrate physical server discovery.

    From the available guidance, the recommended path when discovery or software inventory fails due to appliance-side issues (such as agent or service problems) is:

    1. Check whether the issue surfaces as one of the documented software inventory or discovery errors (for example 10002, 9006–9008, 9011, 9012, 9017, 9009, 9010, 9021–9026, 9032, 60001, 60002, 60005, 9014, 9015, 9016). If a matching error appears in the Azure Migrate portal, follow the remediation steps for that specific error.
    2. If the problem is transient (as indicated for several 9xxx and 10xxx errors), wait for the next discovery cycle (up to 24 hours) and verify if it self-resolves.
    3. If the issue persists or does not map to one of the documented error codes, open a Microsoft support case and provide the Azure Migrate appliance machine ID (shown in the footer of the appliance configuration manager). Several entries explicitly direct to support when appliance/discovery internals fail.

    Because the crash scenario for ServerDiscoveryService.exe is not detailed in the available material, the supported action is to engage Microsoft support with appliance details and any error codes shown in the Azure Migrate project notifications.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer