Intel Arc Pro B70 (0xE223): zeMemAllocDevice(512 MiB) aborts in WDDM memory manager under Windows 11 WSL2

The reported abort is in shared/source/os_interface/windows/wddm_memory_manager.cpp at line 1133; start by reading the allocation path around that location and the standalone b70_repro.c sequence described in the issue. Reproduce on the stated Arc Pro B70 Windows 11 WSL2 setup with Level Zero, then trace why a 512 MiB device allocation aborts after two 256 MiB allocations succeed. Done means allocation returns a documented result without aborting, with the reproducer confirming the behavior.

Pre-submission Checklist

• I am using the latest GPU driver version (download center)
• I have searched for similar issues and found none

GPU Hardware

Intel Arc Pro B70 Graphics — 32 GB VRAM

PCI device ID: 0xE223

GPU Detailed Information

GPU: Intel(R) Arc(TM) Pro B70 Graphics

GPU family: Intel(R) Arc(TM) Pro B70 Graphics Family

Device ID: 0xE223

Graphics driver: 32.0.101.9150

Driver date: October 8, 2026

Reported GPU memory through Level Zero: approximately 31,906 MiB

Reported maximum single allocation: 1,024 MiB

Note: Windows WMI reports AdapterRAM as 4,293,918,720 bytes. This value does not accurately represent the card's full 32 GB VRAM capacity.

Driver Installation Details

The Intel Arc Pro B70 graphics drivers were installed and updated using official Intel methods:

Downloaded and manually installed graphics drivers from Intel's official website.

Used Intel Graphics Software to check for and install available updates.

Manually installed the latest available driver package again.

Driver versions tested:

32.0.101.8976 — allocation failure reproduced.

32.0.101.9150 — allocation failure reproduced.

Current driver: 32.0.101.9150

The same failure persisted after updating the driver.

No driver version that successfully handles this allocation under the tested WSL2 configuration has been identified.

Windows Build Information

Operating system: Windows 11 Pro, 64-bit

Windows build: 10.0.26200.9711

Windows release: 25H2

WSL2 distribution: Ubuntu 24.04.5 LTS

WSL version: 3.0.3.0

WSL Linux kernel: 6.18.54.1-1

GPU interface inside WSL2: /dev/dxg

Note: The Get-ComputerInfo PowerShell command reports "Windows 10 Pro" and version "2009" on this system. The actual operating system is Windows 11 Pro, verified through Win32_OperatingSystem and the full Windows build information.

Actual Behavior

A standalone Intel Level Zero C program consistently causes a process abort when requesting a single 512 MiB device-memory allocation on the Intel Arc Pro B70 under Windows 11 Pro and Ubuntu 24.04.5 WSL2.

The failure occurs directly in the Level Zero API without requiring PyTorch, vLLM, Docker, or any AI model.

Observed allocation sequence:

Intel Arc Pro B70 is detected successfully.

First 256 MiB zeMemAllocDevice() allocation succeeds.

Second simultaneous 256 MiB zeMemAllocDevice() allocation succeeds.

Both allocations are successfully freed using zeMemFree().

A subsequent single 512 MiB zeMemAllocDevice() allocation immediately causes a process abort.

Actual output:

Device: Intel(R) Graphics [0xe223] (0xe223)
Allocating first 256 MiB...
First 256 MiB: SUCCESS
Allocating second 256 MiB...
Second 256 MiB: SUCCESS
Allocating single 512 MiB...
Abort was called at 1133 line in file:
./shared/source/os_interface/windows/wddm_memory_manager.cpp
EXIT_CODE=134

The application terminates with SIGABRT, exit code 134.

The 512 MiB allocation does not return a normal Level Zero error result because the process is terminated internally.

The Intel Arc Pro B70 reports approximately 31,906 MiB of total GPU memory and a maximum single allocation size of 1,024 MiB.

Therefore, the failing 512 MiB allocation is below the reported maximum individual allocation size.

The failure persists even though the system can successfully allocate two simultaneous 256 MiB device-memory buffers.

Additional Investigation

Shared unified memory allocations behave differently:

zeMemAllocShared() succeeds with 512 MiB.

zeMemAllocShared() succeeds with 1 GiB.

A 1 GiB shared-memory buffer was successfully written by the GPU and verified through CPU reads with zero errors.

A custom PyTorch XPU allocator using sycl::malloc_shared() also successfully performed GPU operations with 512 MiB and 1 GiB allocations.

These observations suggest that the issue may be specific to the GPU device-memory allocation path under Windows WDDM/WSL2 rather than a general inability to use large memory buffers.

The physical residency of shared memory in dedicated GPU VRAM versus system RAM has not been verified.

The precise root cause of the failure has not been determined.

Independent Verification

The standalone C reproducer was compiled and executed again locally on October 20, 2026, reproducing the same abort.

On October 21, 2026, Intel Unitrace was successfully built and used to record actual Level Zero API calls.

The trace confirms that both 256 MiB allocations and both corresponding free operations return ZE_RESULT_SUCCESS, while the following 512 MiB allocation causes the process to abort without returning an API result.

The failure prevents reliable use of standard GPU device-memory allocations needed by PyTorch XPU and vLLM inference workloads under this configuration.

Expected Behavior

A single 512 MiB GPU device-memory allocation using zeMemAllocDevice() should succeed when sufficient device memory is available and the requested size is supported.

The GPU reports approximately 31,906 MiB of memory and a maximum single allocation size of 1,024 MiB.

Expected result:

zeMemAllocDevice() allocates a 512 MiB device-memory buffer.

The API returns ZE_RESULT_SUCCESS.

The application can use and release the allocation normally.

The application continues without crashing.

If the allocation cannot be fulfilled, the Level Zero API should return an appropriate documented error code rather than aborting the process.

An unsuccessful memory allocation should not cause an internal abort in windows/wddm_memory_manager.cpp.

Reproduction Rate

Always reproduces — 100% in repeated local tests.

Steps to Reproduce

Use a system with Intel Arc Pro B70 (device ID 0xE223) and Windows 11 Pro.

Install Intel graphics driver 32.0.101.9150.

The same failure was also reproduced with version 32.0.101.8976.

Start Ubuntu 24.04.5 under WSL2:

wsl -d Ubuntu-24.04

Verify that /dev/dxg exists:

ls -l /dev/dxg

Install required packages:

sudo apt update
sudo apt install -y libze-dev build-essential

Save the complete standalone C source from the Source Code / Reproducer section as b70_repro.c.

Compile:

gcc -O2 -Wall -Wextra b70_repro.c -o b70_repro -lze_loader

Execute:

ulimit -c 0
./b70_repro
echo "EXIT_CODE=$?"

Observe two successful 256 MiB allocations followed by a process abort during the 512 MiB allocation.

The observed exit code is 134 (SIGABRT).

No PyTorch, vLLM, Docker, CUDA, or AI model is required.

Is This a Regression?

Unknown.

The issue has been reproduced with two Intel graphics driver versions. No known working version has been identified.

Last Known Working Driver Version

Unknown.

First Known Failing Driver Version

32.0.101.8976 — earliest tested version known to exhibit the failure.

Also confirmed with 32.0.101.9150.

API Call Logs

Intel Unitrace — Level Zero API Call Log

Intel Unitrace was built from the intel/pti-gpu repository and executed with:

unitrace --call-logging ./b70_repro

Actual captured output:

[222082720289] zeDriverGet: pCount = 0x7ffdbc30a0c4 (Count = 0x0) phDrivers = 0x0
<<<< [222082790280] zeDriverGet [5500 ns] Count = 0x1 -> ZE_RESULT_SUCCESS(0x0)
[222082797451] zeDriverGet: pCount = 0x7ffdbc30a0c4 (Count = 0x1) phDrivers = 0x646694c1ed30 (hDrivers = 0x0)
<<<< [222082799091] zeDriverGet [140 ns] Count = 0x1 hDrivers = 0x646694bfeb88 -> ZE_RESULT_SUCCESS(0x0)
[222082801461] zeDeviceGet: hDriver = 0x646694bfeb88 pCount = 0x7ffdbc30a100 (Count = 0x0) phDevices = 0x0
<<<< [222082803611] zeDeviceGet [600 ns] Count = 0x1 -> ZE_RESULT_SUCCESS(0x0)
[222082805581] zeDeviceGet: hDriver = 0x646694bfeb88 pCount = 0x7ffdbc30a100 (Count = 0x1) phDevices = 0x646694c1ed50 (hDevices = 0x0)
<<<< [222082807001] zeDeviceGet [110 ns] Count = 0x1 hDevices[0] = 0x646694bff0e8 -> ZE_RESULT_SUCCESS(0x0)
[222082809541] zeDeviceGetProperties: hDevice = 0x646694bff0e8 pDeviceProperties = 0x7ffdbc30a120
<<<< [222082811411] zeDeviceGetProperties [610 ns] -> ZE_RESULT_SUCCESS(0x0)
Device: Intel(R) Graphics [0xe223] (0xe223)
[222082822201] zeContextCreate: hDriver = 0x646694bfeb88 desc = 0x7ffdbc30a0e0 {ZE_STRUCTURE_TYPE_CONTEXT_DESC(0xd) 0 0} phContext = 0x7ffdbc30a0c8 (hContext = 0x0)
<<<< [222082841622] zeContextCreate [6241 ns] hContext = 0x646694c1ed78 -> ZE_RESULT_SUCCESS(0x0)
Allocating first 256 MiB...
[222082851552] zeMemAllocDevice: hContext = 0x646694c1ed78 device_desc = 0x7ffdbc30a100 {ZE_STRUCTURE_TYPE_DEVICE_MEM_ALLOC_DESC(0x15) 0 0 0} size = 0x10000000 alignment = 0x1 hDevice = 0x646694bff0e8 pptr = 0x7ffdbc30a0d0 (ptr = 0x0)
<<<< [222083375644] zeMemAllocDevice [521272 ns] ptr = 0xffffb80204000000 -> ZE_RESULT_SUCCESS(0x0)
First 256 MiB: SUCCESS
Allocating second 256 MiB...
[222083388174] zeMemAllocDevice: hContext = 0x646694c1ed78 device_desc = 0x7ffdbc30a100 {ZE_STRUCTURE_TYPE_DEVICE_MEM_ALLOC_DESC(0x15) 0 0 0} size = 0x10000000 alignment = 0x1 hDevice = 0x646694bff0e8 pptr = 0x7ffdbc30a0d8 (ptr = 0x0)
<<<< [222083907085] zeMemAllocDevice [513981 ns] ptr = 0xffffb80214000000 -> ZE_RESULT_SUCCESS(0x0)
Second 256 MiB: SUCCESS
[222083924046] zeMemFree: hContext = 0x646694c1ed78 ptr = 0xffffb80214000000
<<<< [222084039828] zeMemFree [113902 ns] -> ZE_RESULT_SUCCESS(0x0)
[222084045809] zeMemFree: hContext = 0x646694c1ed78 ptr = 0xffffb80204000000
<<<< [222084049539] zeMemFree [1540 ns] -> ZE_RESULT_SUCCESS(0x0)
Allocating single 512 MiB...
[222084052849] zeMemAllocDevice: hContext = 0x646694c1ed78 device_desc = 0x7ffdbc30a100 {ZE_STRUCTURE_TYPE_DEVICE_MEM_ALLOC_DESC(0x15) 0 0 0} size = 0x20000000 alignment = 0x1 hDevice = 0x646694bff0e8 pptr = 0x7ffdbc30a0d0 (ptr = 0xffffb80204000000)
Abort was called at 1133 line in file:
./shared/source/os_interface/windows/wddm_memory_manager.cpp

The Intel Unitrace results directly confirm:

First 256 MiB allocation: ZE_RESULT_SUCCESS.

Second 256 MiB allocation: ZE_RESULT_SUCCESS.

First memory-free operation: ZE_RESULT_SUCCESS.

Second memory-free operation: ZE_RESULT_SUCCESS.

Single 512 MiB allocation: API call begins, but no return is recorded before the process aborts.

The full original log was saved locally as unitrace-console.log.

Windows Event Viewer Logs

Windows Application and System event logs were checked for October 19–21, 2026.

No Event Viewer entry was identified that directly confirms the Level Zero 512 MiB allocation failure.

Potentially relevant but unconfirmed Intel software events:

October 20, 2026 — 17:07:16

Source: Application Hang

Event ID: 1002

Application: IntelGraphicsSoftware.exe

Version: 26.36.2702.2

Result: Application stopped responding and was closed.

October 20, 2026 — 17:07:28–17:07:32

Source: Service Control Manager

Event IDs: 7031 and 7034

Several Intel support and telemetry services terminated unexpectedly.

October 20, 2026 — 12:43:33 and 12:45:11

Source: GSCx64

Event ID: 4

Message: The Intel(R) Graphics System Controller Firmware Interface is being disabled.

No causal relationship between these Windows events and the Level Zero device-memory allocation failure has been established.

The standalone C reproducer and Intel Unitrace provide the direct evidence of the failure.

Crash Dumps / Minidumps

The standalone Level Zero C reproducer terminates with SIGABRT (exit code 134) during a 512 MiB zeMemAllocDevice() allocation.

Error:

Abort was called at 1133 line in file:
./shared/source/os_interface/windows/wddm_memory_manager.cpp
EXIT_CODE=134

No crash dump or minidump has been collected.

Linux core dumps were deliberately disabled during the final Unitrace reproduction using:

ulimit -c 0

No Windows kernel crash or BSOD has been observed or confirmed.

A separate dump can be collected if required by Intel engineering.

Source Code / Reproducer

Standalone Intel Level Zero C Reproducer

Filename: b70_repro.c

This standalone C program reproduces the Intel Arc Pro B70 device-memory allocation failure under Windows 11 / WSL2.

The program explicitly selects the Intel GPU with device ID 0xE223, allocates two simultaneous 256 MiB device-memory buffers, frees both, and attempts a single 512 MiB device-memory allocation.

Complete source code:

#include <level_zero/ze_api.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

#define MIB (1024ULL * 1024ULL)

#define CHECK(call) do { ze_result_t result = (call); if (result != ZE_RESULT_SUCCESS) { fprintf(stderr, "%s failed: 0x%x\n", #call, (unsigned)result); return 1; } } while (0)

int main(void) {
setbuf(stdout, NULL);
CHECK(zeInit(0));

uint32_t count = 0;
CHECK(zeDriverGet(&count, NULL));

ze_driver_handle_t *drivers = calloc(count, sizeof(*drivers));
CHECK(zeDriverGet(&count, drivers));

ze_driver_handle_t driver = NULL;
ze_device_handle_t device = NULL;

for (uint32_t i = 0; i < count; i++) {
    uint32_t n = 0;
    CHECK(zeDeviceGet(drivers[i], &n, NULL));
    if (!n) continue;

    ze_device_handle_t *devices =
        calloc(n, sizeof(*devices));

    CHECK(zeDeviceGet(drivers[i], &n, devices));

    for (uint32_t j = 0; j < n; j++) {
        ze_device_properties_t p = {
            .stype = ZE_STRUCTURE_TYPE_DEVICE_PROPERTIES
        };

        CHECK(zeDeviceGetProperties(devices[j], &p));

        printf("Device: %s (0x%x)\n",
               p.name, p.deviceId);

        if (p.deviceId == 0xe223) {
            driver = drivers[i];
            device = devices[j];
        }
    }

    free(devices);
}

if (!device) {
    fprintf(stderr, "Intel B70 0xe223 not found\n");
    return 2;
}

ze_context_desc_t cd = {
    .stype = ZE_STRUCTURE_TYPE_CONTEXT_DESC
};

ze_context_handle_t ctx;
CHECK(zeContextCreate(driver, &cd, &ctx));

ze_device_mem_alloc_desc_t ad = {
    .stype = ZE_STRUCTURE_TYPE_DEVICE_MEM_ALLOC_DESC,
    .ordinal = 0
};

void *a = NULL;
void *b = NULL;

puts("Allocating first 256 MiB...");
CHECK(zeMemAllocDevice(
    ctx, &ad, 256*MIB, 1, device, &a));
puts("First 256 MiB: SUCCESS");

puts("Allocating second 256 MiB...");
CHECK(zeMemAllocDevice(
    ctx, &ad, 256*MIB, 1, device, &b));
puts("Second 256 MiB: SUCCESS");

CHECK(zeMemFree(ctx, b));
CHECK(zeMemFree(ctx, a));

puts("Allocating single 512 MiB...");

ze_result_t r =
    zeMemAllocDevice(
        ctx, &ad, 512*MIB, 1, device, &a);

printf("512 MiB result: 0x%x\n",
       (unsigned)r);

if (r == ZE_RESULT_SUCCESS) {
    puts("512 MiB: SUCCESS");
    CHECK(zeMemFree(ctx, a));
}

CHECK(zeContextDestroy(ctx));
free(drivers);

return r == ZE_RESULT_SUCCESS ? 0 : 3;

}

Compilation:

gcc -O2 -Wall -Wextra b70_repro.c -o b70_repro -lze_loader

Execution:

ulimit -c 0
./b70_repro
echo "EXIT_CODE=$?"

Confirmed failure:

Device: Intel(R) Graphics [0xe223] (0xe223)
Allocating first 256 MiB...
First 256 MiB: SUCCESS
Allocating second 256 MiB...
Second 256 MiB: SUCCESS
Allocating single 512 MiB...
Abort was called at 1133 line in file:
./shared/source/os_interface/windows/wddm_memory_manager.cpp
EXIT_CODE=134

The original standalone reproducer with equivalent allocation logic was compiled and executed locally on October 20, 2026, confirming this failure.

The macro above uses a single-line definition to avoid formatting-related compilation errors when copying the code from GitHub.

The exact single-line formatting has not been separately retested, but it preserves the behavior of the original multiline macro.

Intel Unitrace independently confirmed the failing API call on October 21, 2026.

No PyTorch, vLLM, Docker, or AI model is required.

Command Line / Application Details

Application: Standalone Intel Level Zero C reproducer

Operating system: Windows 11 Pro, build 26200.9711

Linux environment: Ubuntu 24.04.5 LTS under WSL2

GPU: Intel Arc Pro B70 (0xE223)

Intel graphics driver: 32.0.101.9150

Also reproduced with: 32.0.101.8976

Install prerequisites:

sudo apt update
sudo apt install -y libze-dev build-essential

Compile:

gcc -O2 -Wall -Wextra b70_repro.c -o b70_repro -lze_loader

Run:

ulimit -c 0
./b70_repro
echo "EXIT_CODE=$?"

To collect an Intel Unitrace API log when Unitrace is available:

unitrace --call-logging ./b70_repro

Observed behavior:

Two simultaneous 256 MiB device allocations succeed.

Both allocations can be freed successfully.

A subsequent single 512 MiB device allocation aborts the process.

Exit code: 134 (SIGABRT).

oneAPI Version (If Applicable)

Intel Level Zero runtime and development components installed under Ubuntu 24.04.5 WSL2:

libze-intel-gpu1: 26.31.39395.16-124.04ppa1

intel-opencl-icd: 26.31.39395.16-124.04ppa1

libze1: 1.32.0

libze-dev: 1.32.0

The standalone reproducer directly uses the Intel Level Zero API through libze_loader.

No oneAPI DPC++ compiler is required to reproduce the issue.

Intel Unitrace was built from the intel/pti-gpu repository.

The complete installed Intel oneAPI Toolkit and DPC++ compiler versions have not been verified.

System Configuration

Operating System:

Windows 11 Pro, 64-bit

Windows build: 10.0.26200.9711

Processor:

AMD Ryzen 9 9950X

16 cores / 32 threads

Memory:

96 GB DDR5 RAM

2 × 48 GB Corsair, 6000 MT/s

Motherboard:

ASUS ProArt X870E-CREATOR WIFI

BIOS:

Version 1804

Graphics Cards:

Intel Arc Pro B70

32 GB VRAM

Device ID: 0xE223

Driver: 32.0.101.9150

Also affected: 32.0.101.8976

NVIDIA GeForce RTX 5070 Ti

16 GB VRAM

Driver: 32.0.16.1088

AMD Radeon Graphics

Integrated GPU

Driver: 32.0.21042.62

WSL2 Environment:

Ubuntu 24.04.5 LTS

WSL version: 3.0.3.0

Linux kernel: 6.18.54.1-1

GPU interface: /dev/dxg

The system contains three GPUs. The standalone reproducer explicitly selects the Intel Arc Pro B70 (device ID 0xE223).

The presence of the NVIDIA and AMD GPUs has not been established as a contributing factor.

Screenshots / Video

No screenshots or video are required to reproduce the failure.

The standalone test output and actual Intel Unitrace API call log are provided above.

Intel System Support Utility Report

Not collected.

Detailed operating system, driver, GPU, CPU, RAM, motherboard, BIOS, and WSL2 information is included in this report.

Additional Notes

The most important finding is that the issue is reproducible without a machine learning framework.

Intel Unitrace confirms that the Level Zero runtime successfully processes two simultaneous 256 MiB device-memory allocations, frees both, and then aborts during a single 512 MiB device-memory allocation.

Shared memory allocations using zeMemAllocShared() do not exhibit the same failure at the tested 512 MiB and 1 GiB sizes.

This difference may help narrow the investigation to the device-memory allocation path under Windows WDDM/WSL2.

I would appreciate confirmation from Intel engineering regarding whether this is a known WSL2 limitation, a driver defect, or another issue in the device-memory allocation path.

The investigation, reproducer development, and report preparation were assisted by ChatGPT. All reported hardware test results were obtained through actual local execution on the affected system, not simulated tests.