HLK test failing for a KMDF driver with error “A lower driver failed IRP_MN_QUERY_STOP_DEVICE”
Subject: HLK DF‑PNP Rebalance Fail Restart Device: E: target widens to all volumes; QueryStop fails even without my driver installed. Hi all, I’m trying to pass all HLK tests for my driver. Driver: KMDF PnP volume upper‑filter (attached via UpperFilters to the Volume/Disk class) OS: Windows Server 2016 Datacenter, build 14393 HLK: 10.1.14393.8069 Test: DF - PNP Rebalance Fail Restart Device (Reliability) Target volume: E: (NTFS) Storage: PERC H330 Mini (DELL) (HBA) Observed behavior The DQ initially targets E:, but the test later widens to all STORAGE\Volume devnodes: WDTF_TARGETS : INFO : - Query("IsDevice AND (DriverBinaryNames!='i8042prt.sys') AND (Class!=hdc) AND (Class!=scsiadapter) AND (DsmDevice!=TRUE) AND (IsDevice AND (DriverBinaryNames!='i8042prt.sys') AND (Class!=hdc) AND (Class!=scsiadapter) AND (DsmDevice!=TRUE) AND (DeviceID='STORAGE\VOLUME{01FEB6F1-3717-11F1-9707-806E6F6E6963}#0000000001000000'))") WDTF_TARGETS : INFO : Target: Volume (E:) STORAGE\VOLUME{01FEB6.. WDTF_SUPPORT : INFO : - ClearSetupAPILogs() WDTF_TARGETS : INFO : - Query("IsDevice AND (SemiUniqueTargetHardwareIdentifier='STORAGE\Volume')") WDTF_TARGETS : INFO : Target: Volume STORAGE\VOLUME{01FEB6.. WDTF_TARGETS : INFO : Target: Volume STORAGE\VOLUME{01FEB6.. WDTF_TARGETS : INFO : Target: Volume (C:) STORAGE\VOLUME{01FEB6.. WDTF_TARGETS : INFO : Target: Volume (E:) STORAGE\VOLUME{01FEB6.. Failures report A lower driver failed IRP_MN_QUERY_STOP_DEVICE and PNP.RestartDevice() Win32=1 - Incorrect function. For each of the 4 target volumes, it shows this error, DTF_PNP : INFO : - EDTTryStopDeviceFailRestart() WDTF_PNP : INFO : Target: Volume (C:) STORAGE\VOLUME{01FEB6EF-3717-11F1-9707-806E6F6E6963}#000000001F500000 WDTF_PNP : INFO : Result: A lower driver failed IRP_MN_QUERY_STOP_DEVICE. Rebalance tests cannot proceed... WDTF_PNP : INFO : - EDTTryStopDeviceFailRestart() WDTF_PNP : INFO : Target: Volume (E:) STORAGE\VOLUME{01FEB6F1-3717-11F1-9707-806E6F6E6963}#0000000001000000 WDTF_PNP : INFO : Result: A lower driver failed IRP_MN_QUERY_STOP_DEVICE. Rebalance tests cannot proceed... WDTF_PNP : ERROR : PNP.RestartDevice() Win32=1 - Incorrect function. WDTF_PNP : ERROR : PNP.RestartDevice() Win32=1 - Incorrect function. Q1. I have tried multiple variations of the DQ query, and each successfully targets the E volume only. Why does this test later widen to all volumes even when DQ targets only E:? How can I force it to stay on E: ? Q2. I also ran this on a physical server client and a VM client, but faced the same issue both times. I understand the system/boot volume may veto QueryStop, but why does each volume report ‘a lower driver failed IRP_MN_QUERY_STOP_DEVICE’ in this test? Q3. I uninstalled my driver completely and still see the same failures when the test is running with only inbox drivers (e.g., msdmfilt.sys, volsnap.sys, volume.sys) listed by Driver Verifier for target E in the logs. That makes me suspect setup/config rather than my driver. Why would only these drivers fail the test as well, what am I missing here? WDTF_DRIVER_VERIFIER : INFO : - EnableOnAllDriversOfDevices() WDTF_DRIVER_VERIFIER : INFO : Target: Volume (E:) STORAGE\VOLUME{01FEB6F1-3717-11F1-9707-806E6F6E6963}#0000000001000000 WDTF_DRIVER_VERIFIER : INFO : Driver: msdmfilt.sys WDTF_DRIVER_VERIFIER : INFO : Driver: volsnap.sys WDTF_DRIVER_VERIFIER : INFO : Driver: volume.sys Thanks for any guidance!Moving Petabytes Without the Panic: At-Scale Storage Assessments and Migrations to Azure
Hello Folks! If you have ever been asked to move all our file shares to the cloud ASAP. You already know that storage migration is one of those projects that looks easy on a slide and gets ugly in reality. In this session at the Microsoft Azure Infra Summit 2026, Anusha Subramanian and Madhuri Narayana Rao (both Product Managers on the Azure Storage team) walked through a guided roadmap for discovering, assessing, and moving large-scale storage to Azure without the homegrown scripts and the late-night reruns. 📺 Watch the session: Why IT Pros Should Care In short, this session matters because data migration is consistently underestimated. Anusha put it well: customers focus on migrating applications and workloads, and the big chunk of storage those apps depend on tends to be an afterthought. That afterthought is where projects go sideways. Wrong target tier, wrong tool, wrong sizing, and suddenly you are unwinding an architecture six months in. Here is what you get out of the new tooling Anusha and Madhuri covered: A first-party, end-to-end path from discovery to assessment to cutover, all inside services you already pay for. File share discovery and assessment now generally available in Azure Migrate, so you stop guessing about your on-premises estate. A fully managed online migration service (Azure Storage Mover) that handles retries, logging, bandwidth, and scheduling for you. An offline option (Azure Data Box) for when your network is the bottleneck and you are staring down hundreds of terabytes. A partner program (the Storage Migration Program) that covers the edge cases first-party tools do not yet cover, with the ISV software cost picked up by Azure. If you manage file servers, NAS, or large object stores and you have a migration on your roadmap, this is your toolkit. What This Toolkit Does: Technical Overview The session framed large-scale storage migration as a guided roadmap with clear phases. You discover what you have on premises, assess how it is used, pick the right cloud target, decide on a migration strategy, execute in phases, and then run post-migration checks before you cut over. The point of the new tooling is to make each of those steps repeatable instead of bespoke. Three services do most of the heavy lifting: Azure Migrate file share assessment (generally available). Azure Migrate has been Microsoft’s first-party migration platform for a while, but until recently it was very compute-focused (think VMware, Hyper-V, and physical server lift-and-shift). The new capability extends that same discovery appliance to the file shares hosted on those servers. You get share inventory, OS type, protocol, capacity, and basic performance metrics like IOPS and throughput, all flowing back into your Azure Migrate project automatically. Azure Storage Mover. This is the fully managed online migration service. It moves files and folders to Azure without custom scripts or migration infrastructure that you have to babysit. It supports on-premises SMB and NFS sources, cloud-to-cloud moves within Azure (for example, Blob container to Blob container), and AWS S3 to Azure Blob today (with more clouds on the roadmap). Azure Data Box. The offline path. Ruggedized, encrypted, shipped to your datacenter, copied locally, shipped back, and ingested into Azure Storage. The current SKUs include 7 TB disks, 120 TB devices, and 525 TB devices, with 256-bit AES encryption end to end. How It Works Under the Hood For Azure Migrate file share assessment, you download (or update) the Migrate appliance and deploy it on your VMware, Hyper-V, or physical server estate. Grant the required permissions, and the appliance starts collecting share metadata and performance telemetry. That data flows back into your Azure Migrate project, and you see file shares appear as first-class entities in the Infrastructure tab right alongside servers. From there you can tag shares, scope them into groups, and generate assessments that map each share to a recommended Azure Files SKU, give you a TCO estimate, surface readiness blockers, and recommend a migration tool. You can export the whole thing to Excel or PowerPoint, which is exactly what you need when finance asks for the business case. For Storage Mover, the key architectural detail is that the data path is separate from the management path. You deploy a Storage Mover agent close to your source (on premises, in another cloud, or wherever the data lives). The Storage Mover resource in Azure can sit in any region. The agent pulls data from SMB or NFS, then pushes it via REST API directly to the target storage account. Only logs and metadata flow through the service itself. That means migration velocity is governed by the proximity between the agent and the target storage account, not by the region of the management resource. SMB credentials are stored in Azure Key Vault, the agent fetches them at runtime, and one central Storage Mover resource can manage agents deployed globally. Data Box is conceptually simpler. Order the device through the Azure portal, receive it, copy locally over your LAN at LAN speeds, ship it back, and Azure ingests the data into the storage account you specified. The Data Box family is documented at the Microsoft Learn link in the Resources section below. Real-World Value Where does this actually pay off? A few scenarios came up in the session. Lift-and-shift of file servers. Discover with Azure Migrate, assess, get target SKU recommendations and TCO, then move with Storage Mover. Permissions, metadata, and folder structure are preserved during the copy. Cloud-to-cloud (AWS S3 to Azure Blob). The session demoed the multi-cloud connector workflow: deploy a Storage Mover resource, add an AWS connector with an Inventory and Storage Data Management solution, run the AWS CloudFormation template, then create a project, a job definition, and start the job. It is portal-driven from beginning to end. Petabyte-scale offline lift. When you cannot saturate your production WAN for weeks, Data Box gets your seed data to Azure. Then Storage Mover handles the automated delta sync so the cutover window stays small. Recurring incremental sync. Storage Mover now supports recurring schedules (one-time, daily, weekly, or monthly) combined with bandwidth management for peak and off-peak windows. That is useful when data is being collected continuously on premises and you want predictable, throttled transfers. Sovereign cloud. Storage Mover is now available in Azure US Government, so federal and public sector customers can run the same workflow inside their sovereign environment. Specialized scenarios. For source-target pairs the first-party services do not cover yet (say, on-premises NetApp to Azure NetApp Files, which Anusha confirmed in the live Q&A is not yet in Azure Migrate’s scope), the Storage Migration Program brings in partners like Atempo, Data Dynamics, Cirrus Data, and Cirrata. The ISV software cost is covered by Azure. The honest tradeoff: Storage Mover assumes a reasonable network connection between the agent and the target. If the pipe is tiny and the dataset is huge, the math does not work and you should be ordering Data Box hardware. The session was clear about this, and that kind of “use the right tool” guidance is exactly what saves projects. Getting Started If you are kicking off a storage migration, here is the practical sequence. Stand up (or update) an Azure Migrate project and deploy the Migrate appliance on premises. If you already have one, just update to the latest version so file share discovery lights up automatically. Let discovery run, then create an Azure Files assessment scoped to the shares you care about. Pick your region, redundancy, performance look-back window, and percentile utilization. Export the results to Excel or PowerPoint and use it to build your business case. Decide online vs offline based on your dataset size and available bandwidth. Most projects can use Storage Mover. The biggest ones, or the ones with constrained WAN, start with Data Box seed data and then incremental sync with Storage Mover. For Storage Mover, create the resource, deploy the agent close to your data, register it, define endpoints, create a project and job definition, and start the job. Configure bandwidth schedules so your production traffic does not suffer. For specialized source-target pairs, reach out via the Storage Migration Program contact (azstoragemigration at microsoft.com) and engage a listed partner. Resources Azure Migrate file share assessment overview Azure Storage Mover documentation Azure Data Box documentation Azure Data Box overview (SKUs and capacities) Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre Roman
Unable to Build Switchless Storage using Network ATC
3-Node HV/S2D Cluster using Switchless Storage and Network ATC getting Network HUD Error I have a Dell 3-node server cluster being used to host Hyper-V with S2D. Each node is identical and certified to pass S2D requirements. The networking consists of 2 onboard 1 Gbps and 2 quad-port PCI(e) NICs at 10/25 Gbps. The 2 onboard ports are being used for the management intent, 2 ports from each of those NICs are being connected to 2 top-of-rack switches for the compute intent at a total of 12 10 Gbps connections, and the other 2 ports from each of those NICs are being connected directly to the other nodes in a dual mesh method for the storage intent at a total of 6 25 Gbps connections. Very similar to the Microsoft diagram for a three-node storage switchless, dual TOR, dual link deployment network reference pattern for Azure Local, but I am using Windows Server 2025 Datacenter, not Azure Local. The problem I am encountering is when I attempt to create the switchless storage intent, I get an error (shown below) that reads "Failed to fetch physical NIC mapping from the Network HUD service. Please diagnose..." If I leave off the switchless option, it builds without issue. The error only occurs when I attempt to use the switchless option. I tried without configuring the NIC IP addresses first, as well as trying configuring the NIC IP addresses beforehand. I tried without having a cluster built first, as well as building a failover cluster without storage before running the network intent command. The error I posted below shows my last attempt after having the NICs configured with IP addresses and having a failover cluster established before running the command. The error has remained the same throughout the process. Has anyone else run into an issue like this with switchless storage? It seems like everything that I am trying to do is within scope and should be a supported solution. My fallback plan is to use my existing switches, but that drops my connection speeds down from 25 Gbps to 10 Gbps due to hardware limitations.
Moving files out of unlinked, unsynced and disabled onedrive
I am out of storage space on my PC -Windows 11 and get reminders of that everyday. To help solve that problem I would like to move MyDocuments (a huge file) to Drive D. Here is the potential problem. I unlinked, unsynced and removed OneDrive in 2020, or so I thought. I still see the OneDrive symbol in Microsoft Explorer above the line from Drive C and other drives. Most of my files are accessible in Drive C, but not MyDocuments, Desktop, and some others. They can only be opened thru OneDrive. This always puzzled me, but since all my files are accessible to me, I haven't worried about it. Now I'm concerned that OneDrive still has its tentacles around some of my files. MyDocuments and Desktop are being updated, but my files in the cloud are seriously out of date. What does that tell me? If they are still tied to OneDrive somehow, does that complicate the removal of those files to Drive D?
Multiple Namespace Detection in Windows NVMe Over TCP Initiator
We are evaluating the Windows NVMe Initiator and have observed an issue with namespace handling. Our NVMe subsystem contains multiple namespaces. When we connect to the subsystem over TCP and establish connections to all namespaces, they are all shown as connected under the controller. However, only one namespace (shared block device) is exposed and accessible within Windows. Based on our testing, it appears that the initiator may be mapping only the first namespace associated with a given Friendly Name. We were able to connect another subsystem, whose friendly name was different. Questions: Is support for multiple namespaces within a single subsystem currently available in the Windows NVMe Initiator? If so, are there any configuration requirements or known limitations related to namespace discovery and mapping? Is the initiator expected to expose all connected namespaces as separate disks within Windows? We would appreciate any guidance or clarification on the expected behavior.
OneDrive Taking up space on C: even when nothing is being kept on device.
Recently got a new device and had all my files on the previous device synced to my OneDrive. The C drive has about 120 GB of my data (including OS) but when I check my Disk space, I only have 5GB remaining out of 256. However, OneDrive seems to be taking about 150 GB on the disk even though all the files have the cloud icons on it.Teamcenter on Oracle AI Database@Azure: Architecture, Validation, and Results
Teamcenter on Azure with Oracle Exadata Database@Azure delivers seamless, low-latency connectivity between Teamcenter application tiers and Exadata within the same Azure region, combining Azure-native services with Oracle RAC-powered database capabilities. Successful end-to-end functional validation confirmed application compatibility, workload execution, backup and recovery, and stable database performance, demonstrating enterprise readiness for Teamcenter workloads.
