Re: Xenvif non-zero byte assertion error during teardown

[Owen Smith <owen.smith@xxxxxxxxxx>]

Hi,

Does this imply that something has written to these padding bytes?

_XENVIF_FRONTEND is allocated and zeroed with RtlZeroMemory - so all bytes
should be 0 initially. Nothing should access these padding bytes directly, so 
the
ASSERT should be valid

Owen

________________________________________
From: win-pv-devel <win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx> on behalf of Tu 
Dinh <ngoc-tu.dinh@xxxxxxxxxx>
Sent: 03 July 2026 8:30 PM
To: win-pv-devel
Subject: Xenvif non-zero byte assertion error during teardown

Hello,

It's possible for xenvif to hit an assertion error during teardown due
to non-zero bytes in the _XENVIF_FRONTEND struct:

xenvif|_IsZeroMemory: FrontendTeardown: non-zero byte in Frontend
(0xFFFF84857C8D6AD0+0x64)
xenvif|FrontendTeardown: ASSERTION FAILED: _IsZeroMemory(__FSTREXP
__FUNCTION__  , "Frontend", (Frontend), (sizeof (XENVIF_FRONTEND)))

0x64 belongs to padding area:

0:000> dt xenvif!_XENVIF_FRONTEND
    +0x000 Pdo              : Ptr64 _XENVIF_PDO
    +0x008 Path             : Ptr64 Char
    +0x010 Prefix           : Ptr64 Char
    +0x018 State            : _XENVIF_FRONTEND_STATE
    +0x01c Online           : UChar
    +0x020 Lock             : Uint8B
    +0x028 EjectThread      : Ptr64 _XENVIF_THREAD
    +0x030 EjectEvent       : _KEVENT
    +0x048 BackendPath      : Ptr64 Char
    +0x050 BackendDomain    : Uint2B
    +0x054 MaxQueues        : Uint4B
    +0x058 NumQueues        : Uint4B
    +0x05c Split            : UChar
    +0x060 DisableToeplitz  : Uint4B
    +0x068 Mac              : Ptr64 _XENVIF_MAC
    +0x070 Receiver         : Ptr64 _XENVIF_RECEIVER
    +0x078 Transmitter      : Ptr64 _XENVIF_TRANSMITTER
    +0x080 Controller       : Ptr64 _XENVIF_CONTROLLER
    +0x088 DebugInterface   : _XENBUS_DEBUG_INTERFACE_V1
    +0x0d8 SuspendInterface : _XENBUS_SUSPEND_INTERFACE_V1
    +0x128 StoreInterface   : _XENBUS_STORE_INTERFACE_V2
    +0x1b0 SuspendCallbackEarly : Ptr64 _XENBUS_SUSPEND_CALLBACK
    +0x1b8 SuspendCallbackLate : Ptr64 _XENBUS_SUSPEND_CALLBACK
    +0x1c0 DebugCallback    : Ptr64 _XENBUS_DEBUG_CALLBACK
    +0x1c8 Watch            : Ptr64 _XENBUS_STORE_WATCH
    +0x1d0 Statistics       : Ptr64 _XENVIF_FRONTEND_STATISTICS
    +0x1d8 StatisticsCount  : Uint4B
    +0x1e0 MibThread        : Ptr64 _XENVIF_THREAD
    +0x1e8 Alias            : [257] Char
    +0x2ec InterfaceIndex   : Uint4B
    +0x2f0 AddressTable     : Ptr64 _SOCKADDR_INET
    +0x2f8 AddressCount     : Uint4B
    +0x2fc Hash             : _XENVIF_FRONTEND_HASH

struct _XENVIF_FRONTEND (and likely other structs) are in general full
of similar padding. So the ASSERT(IsZeroMemory(Frontend)) check is too
strict in most cases.

I think current IsZeroMemory asserts should either be removed or
converted to a print-only warning.


--
 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech