Re: Xenvif non-zero byte assertion error during teardown

[Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>]

Hello,

On 06/07/2026 08:54, Owen Smith wrote:
> 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

Yes, I think that's likely the case. Struct padding bytes have 
unspecified values and compilers are free to emit code that overwrite 
them even if we don't access them directly.

> 
> 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
> 



--
Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech