Question about memory boundary alignment during struct and Union storage (2)

In the new blog, it seems that the function of modifying the previously written blog is no longer available.
In the DEBUG version, it seems that the padding byte is 0xCC, and 0xCC is the machine code of the int 3 interrupt command. In the release version, the padding of bytes does not seem to be regular.
The following is the code in winnt. h:

// Winnt. h line 4947
# Ifndef _ MAC

# Include "pshpack4.h" // 4 byte packing is the default

# Define IMAGE_DOS_SIGNATURE 0x5A4D // MZ
# Define IMAGE_OS2_SIGNATURE 0x454E // NE
# Define IMAGE_OS2_SIGNATURE_LE 0x454C // LE
# Define IMAGE_VXD_SIGNATURE 0x454C // LE
# Define IMAGE_NT_SIGNATURE 0x00004550 // PE00

# Include "pshpack2.h" // 16 bit headers are 2 byte packed

# Else

# Include "pshpack1.h"

# Define IMAGE_DOS_SIGNATURE 0x4D5A // MZ
# Define IMAGE_OS2_SIGNATURE 0x4E45 // NE
# Define IMAGE_OS2_SIGNATURE_LE 0x4C45 // LE
# Define IMAGE_NT_SIGNATURE 0x50450000 // PE00
# Endif

From the above definition, we can see that when 4-byte alignment and 1-byte alignment, the macro defined byte order is different. In intel chips, storage is low-address storage and Low-byte storage. Therefore, when the 4-byte alignment occurs, 0x0102 is stored in the memory, which is normal. However, the 1-byte alignment is all defined according to the reading order of people. I think it may be because the alignment of memory boundary affects the byte sequence of data storage, but the write program test shows that no matter how many bytes the boundary alignment of memory only affects the size of the structure, it does not affect the byte sequence of data storage.