wezterm/wezterm · warning · std::io::Error

Can't get the size of Shared Memory, VirtualQuery failed: {:

Error message

Can't get the size of Shared Memory, VirtualQuery failed: {:#}

What it means

Once the view is mapped, the Windows shm reader calls VirtualQuery on the base pointer to learn the region size (needed to bound the copy). A zero return means the query could not describe the region, reported as ErrorKind::Other 'Can't get the size of Shared Memory, VirtualQuery failed: {os error}'. This is a near-impossible path for a valid open mapping+view; it indicates the view became invalid between mapping and querying.

Source

Thrown at wezterm-escape-parser/src/apc.rs:403

            ));
        }

        let shm = SharedMemObject {
            _handle: handle_wrapper,
            buf,
        };

        let mut memory_info = MEMORY_BASIC_INFORMATION::default();
        let res = unsafe {
            VirtualQuery(
                shm.buf.Value,
                &mut memory_info,
                std::mem::size_of::<MEMORY_BASIC_INFORMATION>(),
            )
        };
        if res == 0 {
            let err = std::io::Error::last_os_error();
            return Err(std::io::Error::new(
                std::io::ErrorKind::Other,
                format!(
                    "Can't get the size of Shared Memory, VirtualQuery failed: {:#}",
                    err
                ),
            ));
        }
        let mut size = memory_info.RegionSize;
        let offset = data_offset.unwrap_or(0) as usize;
        if offset >= size {
            return Err(std::io::Error::new(
                std::io::ErrorKind::Other,
                format!(
                    "offset {} bigger than or equal to shm region size {}",
                    offset, size
                ),
            ));
        }

View on GitHub (pinned to b99b1ca2cc)

Solutions

Serialize the transfer: producer keeps the mapping alive until the reader signals completion, so the view stays valid through VirtualQuery.
Treat the error as transient and retry the whole transfer once via a different transport (inline base64 or file).
Check for concurrent unmapping/closing code paths in the embedding application.

Defensive patterns

Strategy: retry

Try / catch

match read_shared_memory_data_win(&name, off, size) {
    Ok(data) => Ok(data),
    Err(e) if e.to_string().contains("VirtualQuery") => {
        // transient teardown race: one retry, then fall back to another transport
        Err(e)
    }
    Err(e) => Err(e),
}

Prevention

Never close/unmap the section while the reader is mid-transfer.
Use an explicit ack from reader to writer before teardown.
Log mapping names with timings to correlate races in bug reports.

When it happens

Trigger: Another thread unmapped or closed the view/handle concurrently, or the handle was invalid in a way MapViewOfFile masked; practically only under concurrent teardown of the transfer.

Common situations: Races where the producer closes the mapping while the terminal is mid-read; memory corruption in either process; antivirus/security software interfering with mapped sections.

Related errors

AI-assisted analysis of wezterm/wezterm@b99b1ca2cc (2026-08-20). Data as JSON: /api/errors/426f9cad1a83a334. Report an issue: GitHub.