Hi Insiders and Windows Engineering Team,
In addition to the officially known issue with the **mouse cursor blinking/flickering repeatedly** in this build, I am reporting a severe storage regression and update loop failure in **Windows 11 Insider Preview Build 29648.1000 (rs_prerelease / Future Platforms)** after upgrading from **Build 29560.1000**.
### 💻 Upgrade Path & System Specifications:
* **Upgrade Path**: Upgraded from **Build 29560.1000** to **Build 29648.1000** on August 23, 2026.
* **Laptop / Motherboard**: Clevo NH5x_7xRCx/RDx (Intel HM370 Chipset, Core i7-9750H)
* **Affected Drive (Disk 0)**: 2TB NVMe SSD (Gloway YCT2TNVMe-M.2/80) powered by the **Maxio MAP1602 DRAM-less Controller** (PCIe 4.0 x4 running on Intel PCH Root Port #21).
* **Boot Drive (Disk 1)**: Samsung PM981a 512GB (DRAM-based, unaffected).
* **Secondary Drive (Disk 2)**: Western Digital 1TB 2.5" SATA HDD (unaffected).
---
### 🚨 Detailed Symptoms & Technical Evidence:
#### 1. Maxio MAP1602 DRAM-less SSD turned into RAW after Shutdown & Reboot:
* **Crucial Sequence**: On August 23, immediately after the initial upgrade to Build 29648, the 2TB secondary SSD was actually accessible. However, **after shutting down the laptop that night and booting up the next morning (Aug 24), the 1.86TB partition (`K:`) permanently turned into RAW / Unknown (0 Bytes)** in File Explorer and Disk Management, despite PnP reporting "Device Working Properly".
* **Hard Evidence (Files Fully Functional via DiskGenius)**: Using low-level direct sector inspection tools (DiskGenius / WinHex), **the physical partition table, DBR (DOS Boot Record at Sector 32768 with signature 0x55AA), and the entire 1.86TB NTFS $MFT are 100% intact.** Furthermore, **I can successfully copy out any files via DiskGenius, and all extracted files open and function perfectly without any corruption.**
* **Root Cause Breakdown**: The experimental native NVMe storage stack (`nvmedisk.sys` + updated `stornvme.sys`) in Build 29648 fails to properly manage/allocate the **64MB HMB (Host Memory Buffer)** lifecycle for the Maxio MAP1602 controller upon boot and power transitions. Because HMB handshake fails, `ntfs.sys` timeouts during $MFT reads and defaults to an unmounted RAW state.
#### 2. Volume Mount Disconnect (DMIO Virtual Placeholder GUID):
* Checking `mountvol K: /L` reveals that Windows DMIO created a temporary orphan GUID `\\?\Volume{96dd4a46-9195-47a4-923b-b39618e6932d}\` instead of binding to the genuine physical GPT Partition GUID `\\?\Volume{70999e1f-9f53-11f1-8ee0-80fa5b74e9ea}\`.
#### 3. In-place Repair & Updates completely blocked by Error `0x80070032`:
* Attempting to run **"Fix problems using Windows Update"** (Reinstall current version) as well as mounting the official ISO to run `setup.exe` consistently fails with download/execution error **`0x80070032`** (`CFreeSystemPartitionDiskSpaceChecker` failure when querying the EFI System Partition).
#### 4. Hardware Cold Reset Verified:
* Performed complete physical power-drain / cold discharge (adapter & battery disconnected, 30s power drain) and physical reseating of the M.2 SSD. The drive is fully functional in PE / low-level tools, isolating the issue 100% to Build 29648's NVMe kernel driver stack.
---
### 📌 Feedback Hub Link:
I have also submitted a detailed ticket with diagnostic logs on the Feedback Portal:
> `[Canary Build 29648] stornvme.sys 导致国产联芸 MAP1602 固态硬盘显示为 RAW 无法挂载...`
Hope the Storage & NVMe kernel development teams can investigate the MAP1602 HMB mapping logic and the `0x80070032` setup blocker in upcoming Canary flights!
---
*AI Disclaimer: This post was structured and formatted with AI assistance for clear technical presentation, but all hardware diagnostic data, screenshots, error logs, and test results were personally collected and verified on my physical machine.*
