Azure Migrate Hyper-V – Project-wide Dependency Analysis map not rendering and recurring AcquireLockFailedAbort

Hello Microsoft Support,

We are running an Azure Migrate PoC for Hyper-V using agentless discovery and dependency analysis. Discovery, software inventory, and per-server dependency analysis are working, but the project-wide Dependency Analysis / Explore Applications visualization does not render any dependency map.

Environment

Subscription: ctc-tv-azuremigrate-sub-agentless

Resource Group: rg-azure-migrate-lab

Azure Migrate project: azm-hyperv-lab

Project geography: Asia Pacific

Connectivity: Public endpoint

Target migration region: Southeast Asia

Appliance: azhvappliance

Appliance IP: 192.168.0.30

Appliance OS: Windows Server 2022 Datacenter Evaluation, Build 20348

Hyper-V host: NHAN-PC

Hyper-V host IP: 192.168.0.184

Source platform: Hyper-V on Windows 10 Pro lab host

Discovery agent version: 2.0.3427.745

Six Linux workload VMs are in dependency-analysis scope:

ansible-controller

k8s-master

k8s-worker1

k8s-worker2

k8s-worker3

jenkins-server

The Azure Migrate appliance VM itself is discovered by Hyper-V but is intentionally not in migration/assessment scope. Its dependency status is currently Credentials not available because no guest credential was configured for the appliance VM.

What is working

The following functions have been validated successfully:

Azure Migrate appliance registration completed successfully.

Hyper-V source validation completed successfully.

All expected Hyper-V VMs are discovered.

Software inventory is available.

Linux guest credentials are working.

Hyper-V KVP is enabled and Linux IPv4 addresses are correctly discovered.

Per-server Dependency Analysis works.

Example: k8s-master resolves connections to k8s-worker1, k8s-worker2, k8s-worker3, and ansible-controller.

Dependency CSV export contains resolved VM-to-VM relationships.

Appliance dependency collection logs show process and network connection data being collected.

Example previously observed:

NumberOfConnection = 232

NumberOfProcess = 121

The DependencyMap Azure resource exists:

azm-hyperv-lab4680depmap

Discovery source exists and is successfully provisioned:

azhvappliance4786mapsrc

provisioningState = Succeeded

sourceId = Microsoft.OffAzure/HyperVSites/azhvappliance4786site

Appliance diagnostics:

Prerequisite checks: Passed

Service health checks: Passed

Azure-specific checks: Passed

All Azure Migrate appliance services are reported as Up-to-date and Running/Connected.

Relevant versions include:

Discovery agent 2.0.3427.745

Assessment agent 2.0.3488.777

SQL discovery and assessment agent 2.0.3522.716

Web app discovery agent 2.0.3523.636

MySQL agent 2.0.3462.411

PostgreSQL agent 2.0.3402.340

Storage agent 2.0.3530.470

The appliance was also changed from Dynamic Memory / approximately 4 GB visible RAM to 16 GB RAM, followed by a full appliance VM reboot.

Problem

Despite the above, the project-wide:

Azure Migrate → Dependency Analysis → Explore Applications

view does not render the dependency graph.

This is different from per-server dependency views, which work correctly.

Recurring Discovery Agent log behavior

We are also observing recurring:

AcquireLockFailedAbort

ErrorCode: 963

during RefreshDependencyMap.

The important part is that the logs show two internal periodic callbacks for RefreshDependencyMap within the same Discovery Agent session.

At 2026-09-09 05:58:13Z, the log shows both:

Executing with autoreset false, periodic callback

RefreshDependencyMapCallback

duration: 4.9003888516666665 min.

and:

Executing static periodic callback with autoreset true

RefreshDependencyMapCallback

duration: 5 min.

Both subsequently attempt to execute RefreshDependencyMap.

One invocation successfully acquires the semaphore:

Going to acquire Semaphore ::RefreshDependencyMap

Successfully acquired semaphore RefreshDependencyMap

Executing Periodic command RefreshDependencyMap

and completes successfully:

Total time taken for RefreshDependencyMap operation is 5.9817075 seconds

The other invocation appears to wait for the same semaphore and fails approximately 30 seconds later:

05:58:43Z Failed to acquire semaphore RefreshDependencyMap

CommandFailed, 30.0088828

ErrorCode: AcquireLockFailedAbort

The exception message is:

A discovery operation was skipped because the appliance was busy

processing other operations.

The agent then logs:

Ignoring this exception

This same pattern has been observed repeatedly at approximately five-minute intervals.

Both callback paths use the same:

AgentSessionId:

c1faa1cf-ec4f-4d31-9f11-619f739d6f27

Agent type:

HyperVDiscovery

Version:

2.0.3427.745

Therefore, this does not appear to be two separate Windows Discovery Agent processes.

The Windows service is:

Service name : amhvdiscoverysvc

Display name : Microsoft Azure Hyper-V Discovery Service

Executable : HyperVDiscoveryService.exe

State : Running

Start mode : Auto

Only one instance of the Hyper-V Discovery service/process was observed.

Troubleshooting already performed

We have already performed the following:

Increased appliance RAM to 16 GB.

Fully rebooted the appliance VM.

Confirmed appliance services are up-to-date.

Confirmed all relevant services are running/connected.

Confirmed Hyper-V source discovery continues successfully.

Confirmed dependency collection succeeds.

Confirmed per-server dependency maps work.

Confirmed Dependency CSV contains resolved VM-to-VM relationships.

Confirmed DependencyMap resource exists.

Confirmed discovery source provisioning state is Succeeded.

Used Refresh services from Azure Migrate.

Refresh Services did not change the Hyper-V Discovery service PID and did not eliminate the recurring AcquireLockFailedAbort.

We have not deleted/re-added the Hyper-V source.

We have not reinstalled the appliance.

VDDK has not been installed because this is a Hyper-V source, not VMware.

Current assessment

Dependency data collection appears healthy because successful RefreshDependencyMap operations continue and dependency relationships are visible both in per-server maps and CSV exports.

However, the recurring log pattern strongly suggests that two internal periodic RefreshDependencyMap callback paths are being scheduled within the same Discovery Agent session, with one operation succeeding and another timing out while waiting for the internal semaphore.

We cannot determine whether this recurring internal concurrency condition is related to the project-wide Explore Applications visualization not rendering.

Request to Microsoft

Could you please help confirm:

Is it expected behavior for Hyper-V Discovery Agent 2.0.3427.745 to run both:

periodic callback ... autoreset false

static periodic callback ... autoreset true

for RefreshDependencyMap at approximately the same time?

Is recurring AcquireLockFailedAbort / ErrorCode 963 every approximately five minutes a known issue with this Discovery Agent version?

Could this duplicate/concurrent RefreshDependencyMap behavior prevent or delay Azure-side dependency aggregation used by Explore Applications?

Given that per-server maps and resolved dependency CSV data are available, can you verify whether the backend DependencyMap data for project azm-hyperv-lab is being successfully aggregated for the project-wide visualization?

Are there any backend diagnostics or resource states that we should check for:

azm-hyperv-lab4680depmap

azhvappliance4786mapsrc

Is the discovered Azure Migrate appliance VM having Dependencies = Credentials not available expected to be ignored by the project-wide visualization, or could an ineligible discovered VM affect the Explore Applications graph?

We can provide the complete ServiceAria_20260909.log, Dependency CSV export, screenshots of the appliance health status, and screenshots of the blank Explore Applications page if required.

Thank you.