Reference version 1.0

VB6 file format — the structures a VB5/6 image carries

When you compile a Visual Basic 5 or 6 project, the IDE lays a graph of fixed structures into the PE, rooted at the VBHeader, that the MSVBVM runtime walks at load. This page documents those on-disk structures field by field: offset, size, type, meaning, and the gotchas that bite. It covers both P-code and native builds — the structures below are identical in both; only the method-dispatch layer and a few flags differ.

Offsets, sizes and the example values are captured from vbdec itself (its dump() and structIDC output over a loaded sample, PDFStreamDumper); field types and notes are drawn from the vbdec struct sources. Companion references: the P-code opcode reference (and its VB5 vs VB6 section), UDT_DESCRIPTORS.md, VB6_events and RTMI_FIELDS.md for the deeper layers.

Nesting map

How the structures reference each other (blue = the pointer/offset field that reaches the child):

How the loader walks it

1. The PE entry point is a tiny stub that pushes the VBHeader VA and calls the runtime's ThunRTMain. That pushed pointer is how you find the VBHeader without guessing.
2. From VBHeader the runtime reaches ProjectInfo (aProjectInfo), then the ObjectTable (ProjectInfo.aObjectTable).
3. The ObjectTable's lpObjectArray is an array of tObject descriptors (stride 0x30), one per compiled object — not the ObjectInfo records themselves. Each tObject+0x00 (aObjectInfo) points to that object's ObjectInfo. Each ObjectInfo's lpMethods gives its procedures, and designer objects carry an OptionalObjectInfo right after the ObjectInfo with their controls and events.
4. Visual objects are also listed in the GuiTable (VBHeader.aGuiTable), whose aFormPointer reaches the GUIObjectInfo and the serialized control-property blob.
5. External OCX/typelib references live in the external-component table (aExternalComponentTable), and COM-exposed projects carry ComRegData/ComRegInfo (aComRegisterData).

VBHeader (EXEPROJECTINFO)

Reached via PE entry point: the OEP stub is push <VBHeader> ; call ThunRTMain — the pushed pointer IS the VBHeader VA.

The root of every VB5/6 image. Fixed-size header that anchors the whole VB object graph: it points at the ProjectInfo, the GUI table, the external-component table and the COM-registration data, and carries the offsets (relative to its own VA) of the project's name/title/help/exe strings.

ProjectInfo

Reached via VBHeader.aProjectInfo

The compile-time project record: where code starts/ends, the VBA exception handler, the native-code pointer, and the project path string. Most of its address fields are only meaningful at runtime.

ObjectTable

Reached via ProjectInfo.aObjectTable

The catalog of every compiled object (form/class/module/UserControl/UserDocument). lpObjectArray points at an array of tObject descriptors (stride 0x30), not at the ObjectInfo records directly — each tObject+0x00 (aObjectInfo) is the VA of this object's ObjectInfo; ObjectCount1 says how many.

ProjectInfo2

Reached via ObjectTable.aProjectInfo2

Secondary project info: a back-pointer to the ObjectTable, a pointer to the object-descriptor list, and the project description / help-file / help-context.

ObjectInfo (epiModule)

Reached via ObjectTable.lpObjectArray → tObject[i] → +0x00 aObjectInfo

The per-object record (vbdec/runtime name epiModule). It carries the method count, the pointer to this object's methods, the constant pool, and — if the object has a designer/controls — is immediately followed by the OptionalObjectInfo.

OptionalObjectInfo

Reached via Immediately follows ObjectInfo when tObject.ObjectType AND 0x80

Present only for objects with a designer surface (forms, UserControls, classes with events). Holds the object's GUIDs, the controls array, the P-code count, the init/terminate event offsets, and the aMethodLinkTable.

GuiTable

Reached via VBHeader.aGuiTable → one per form / UserControl

Designer record for a visual object: its ObjectGUI UUID, OLEMisc flags, object CLSID, and the pointer (aFormPointer) to the GUIObjectInfo + control property blob.

GUIObjectInfo

Reached via GuiTable.aFormPointer

Header of the control/property blob for a visual object: the control count and the three defining GUIDs (ObjectGUI, DefaultIID, COMEventsIID), followed by the total length of the serialized properties.

ComRegData

Reached via VBHeader.aComRegisterData

Root of the COM-registration block (only present when the project exposes COM objects). Points at the COM-interface info and carries the project/typelib CLSID, LCID and typelib version.

ComRegInfo

Reached via ComRegData.oRegInfo → linked list via oNextObject

One record per COM-exposed object: its name/description offsets, instancing mode, object & control CLSIDs, OLEMisc status, and the Object-Type flag.

Form controls — the serialized property blob

The visual designer packs every control on a form / UserControl into a serialized blob. GuiTable.aFormPointer points at it, it is GuiTable.dataSize bytes long, and parsing starts at aFormPointer + 0x5E (after the GUIObjectInfo header). Inside is a sequence of per-control records, each followed by a dynamic run of 1-byte “control codes” that describe the parent/child control tree. Fair warning from the source: this is the hairiest corner of the whole format — the control-code state machine, not the fixed header, is what makes it hard. (From David Zimmer's Parsing VB6 Form Controls.)

The control header

Each control begins with a fixed header, then its (variable-size) property data to length:

To tell a normal header from an array header, read the high byte of length (the 4th byte): if (b & 0x80) it's an array element. (The “aha” from the paper: it's not a weird 3-byte length + flag byte — it's a 32-bit length that steals the sign bit, which would otherwise be unused, as the isArray flag.)

cType — control type byte

The numbering has gaps (12, 14–15, 21, 25–36, 39) — the runtime's own table has them too.

Control codes (the hairy part)

After a control's fixed struct comes a dynamic, variable-length run of 1-byte codes describing the control tree:

Valid sequences differ between ordinary controls and menus. Hard-won rules from bulk analysis: 03 01 is never valid; 03 03 is valid for a menu but not other controls; 03 04 is valid only when bytesLeft == 0.

Beyond locating the blob: the individual properties

Finding each control's blob is only half the battle; pulling the actual property values (.Caption, .Text, .Height…) is a separate per-control-type slog: the embedded property opcode is memberID − 0x10000, values are variable-size and must be walked in order (you can't jump to the one you want), and the layout differs for every control. vbdec deliberately does not do full form reconstruction; it surfaces the parsed blobs plus an image extractor, an Extract Strings option, and the OLB Viewer (which decodes memberID − 0x10000 to help read the hex by hand).

3rd-party (OCX / ActiveX) controls

For a 3rd-party control the VB header's cType is 0xFF (External) and the real type is a length-prefixed ProgID string at the start of the property data (e.g. "MSComctlLib.ListView"):

[ VB control header: length, cId, cname, null, cType=0xFF ]
[ u16-length ProgID string  e.g. "MSComctlLib.ListView" ]
[ property opcode stream ... to control.length ]

Reversing MSVBVM60 (symboled build) shows the runtime loads every control, intrinsic and OCX alike, through one routine, PropLoadProp(CTL*, FILEREF*) (header via LoadHctlHeader). For intrinsic controls that opcode stream carries all the property values. For an OCX it carries only the VB wrapper (the extender/stock props) plus one object-data opcode whose value is the control's own serialized blob — so the control's own properties are not in this opcode format (see “Full typed decode” below, proven by compile-diff). The mechanism below is therefore exact for intrinsic controls and for the OCX wrapper:

How the runtime parses it — PropLoadProp

• Read a 1-byte property opcode; 0xFF ends the control (the trailing FF in every blob). Opcodes ascend; a gap triggers _PropSetDefaults for the skipped properties. (This stream-terminator 0xFF is unrelated to the header's cType=0xFF — same byte value, different field: one marks “external control”, the other marks “end of property stream”.)
• The opcode indexes the control's property-descriptor table — an array of tagPROP built from the control's type info at load: prop = table[opcode].
• tagPROP+4 is a type+flags dword; its low 6 bits (the base type) decide how the value is read:

Then PropSetControlProperty(CTL*, opcode, value, tagPROP*) applies it: it stores straight into the control's instance-data slot at tagPROP+0x10 (with the right coercion — BSTR alloc, bitfield pack, AddRef for an object, PictSetPicture for a picture) or, when the flag bits say so, calls a control method through its vtable (offset +0x20 / +0x24). That is exactly the "vtable offset to call + property type" model — the type tells the loader how to read the bytes, the descriptor says where/how to apply them.

So the ListView landmarks fit perfectly: the embedded StdFont {0BE35203-8F91-11CE-9DE3-00AA004BB851} is just the Font property's value — an inline IPersistStream-serialized StdFont (its sub-stream holds "Courier New"); a column caption is a BSTR value; GridLines is a one-byte scalar. The whole stream is walkable given the control's property-index→type map. vbdec has that map for intrinsic controls (from vb6.olb); for an OCX you rebuild it from the control's own typelib (TLBINF32 / the OLB Viewer — see tlb_dump.vbs: ListView → IListView, View=dispid 0x12, GridLines=0x1B, stock Font=−512).

Validation (vs source). Decoding the compiled lvDebug blob in PDFStreamDumper reproduces its Form1.frm source exactly: _ExtentX=14949, _ExtentY=2566, _Version=393217, the Font (inline StdFont: "Courier New", 8.25pt, Weight 400), and ColumnHeader(1).Text="Message" all round-trip byte-for-byte — confirming the PropLoadProp type model on a real 3rd-party control.

Is it a VB6 PropertyBag dump? No. A PropertyBag.Contents blob begins with the magic 93 B2 00 00 (0xB293) and stores every property name as a UTF-16LE string (gridlines, view, caption… plainly readable). The control stream has no property-name strings — it is index-keyed via tagPROP, not name-keyed. (A control implementing only IPersistPropertyBag would persist as a name-keyed bag; most intrinsic controls and MSComctlLib use the PropLoadProp stream.)

Full typed decode — the mechanism (how to name every property)

The opcode is an index into the control's property table — an array of tagPROP / tagPROPDEF / tagPROPSHORT pointers in opcode order (each descriptor carries the +4 type/flags, the +0x10 member offset, etc.). Two sources:

• Intrinsic controls: the table is a static array in MSVBVM60 (e.g. the ListBox table is Std_propName, Std_propIndex, BackColor, ForeColor, Left, Top, Width, Height, Enabled, Visible, MousePointer, FontName…, TabIndex, LBox_propList, LBox_propSorted, LBox_propText…). vbdec already encodes this via vb6.olb — which is why intrinsic property values decode today.
• OCX controls: VB's table covers only the wrapper — the extender props (Name, Left, Top, Width, Height, _ExtentX, _ExtentY, _Version…) plus a single object-data property whose value is the control's own IPersistStreamInit::Save blob (loaded via IPersistStream::Load). The control's own properties live inside that blob, in the control's private format — which is not a VB opcode stream at all.

Proven by compile-diff (the definitive answer). Compiling a minimal ListView form and flipping one property at a time shows the control's props are bit-packed with a checksum, not stored as (opcode,value) pairs: View 3→1 changed exactly one data byte (+0x5B: 0x23→0x21, i.e. bits 0–1) plus a 3-byte checksum near the end; LabelEdit 1→0 cleared bit 5 of the same byte (0x23→0x03) and moved the checksum again. So +0x5B holds View (bits 0–1) and LabelEdit (bit 5), MSComctlLib-style. There is therefore no universal OCX property namer — each control family (MSComctlLib, RichTextBox, …) defines its own IPersistStream packing (bitfields, extents, embedded StdFont/items, a checksum), and naming its values means reversing that control's format (readily done by compile-diff, one property at a time). Intrinsic controls remain fully decodable via vb6.olb; for OCX, the universal, format-agnostic answer is the coverage-complete dump (ProgID/Font/Picture/strings + every other byte shown as (unparsed) with its code and raw hex).

So a full OCX property namer needs that per-control ordered table. Build it statically (per the malware rule, never load the sample's control): take VB's fixed stock/extender set + the control's dispinterface property order from a system-registered typelib (or the sample's embedded typelib bytes read statically; see tlb_dump.vbs), map each property's VARTYPE to the PropLoadProp type codes above, then walk the opcode stream. Cache the result like vb6.olb. Until then, vbdec's OCX dumper is coverage-complete — it decodes ProgID / Font / Picture / strings and shows every remaining byte as an (unparsed) entry with its code byte and raw hex, so nothing is hidden.

Prototype & type descriptors (function-signature recovery)

This is one of VB6's most useful — and least known — properties: every public COM object (form, class, UserControl) carries complete type information for its public members, baked in at compile time, with no type library required and no way to disable it. That means the full prototype of every public Sub / Function / Property / Event — argument count, per-argument type, ByRef/ByVal/Optional/Array, return type — plus every public variable's type and in-object offset, can be recovered straight from the binary. (Based on David Zimmer's paper, Recovery of Function Prototypes in Visual Basic 6 Executables.)

The chain: ObjectInfo → lpPrivateObject → PrivateObj, whose three pointers reach the arrays of FuncTypeDesc, PubVarDesc and EventDesc records. A function/event record is a fixed header followed by a packed buffer of type bytes, one per argument (plus one for the return value on a Function / Property Get).

The type byte

Each argument's type is a single byte: a base type from an internal enumeration (not VARENUM), OR-ed with modifier bits. COM/internal types are followed by a 32-bit offset to a reference struct (library GUID, CLSID, name, DLL path).

argSize packs the argument count in its low bits (argCount × 4) and the property kind (Get/Let/Set) in its top 3 bits. flags bit 1 flags a return value. optionalVals set means Optional defaults follow (parsed into the COptParamDefVal records; note an Optional typed as an enum is saved only as its underlying Long). Everything is 32-bit aligned, and null padding can appear between a type byte and its offset and between type bytes — a parser must tolerate it.

PrivateObj

Reached via ObjectInfo.lpPrivateObject

The hub for type/prototype recovery. Carries the public-variable and event counts and the pointers to the three descriptor arrays — functions (lpFuncTypeInfo), public variables (lpPublicVars) and events (lpEventsTypeInfo) — plus a back-link to the owning ObjectInfo.

FuncTypeDesc (public function/property)

Reached via PrivateObj.lpFuncTypeInfo → array, indexed in ProcNamesArray order

One per public Sub/Function/Property. A fixed header followed by a variable-length buffer of per-argument type bytes. argSize encodes the argument count and the property kind; vOff is the vtable offset; lpAryArgNames points at the argument-name strings.

PubVarDesc (public variable)

Reached via PrivateObj.lpPublicVars → array of cntPublicVars

One per public (module-level) variable. VB auto-generates Get/Let (and Set for object types) property accessors for these — vOff gives all three vtable slots. dataOffset is the variable's location relative to the object pointer (ObjPtr()+dataOffset).

EventDesc

Reached via PrivateObj.lpEventsTypeInfo → array of cntEvents

One per declared event. Mirrors the FuncTypeDesc layout (events are prototypes that are only ever raised, never implemented in the defining object). The captured example recovers Event event_1(stream As CPDFStream).

ProcDscInfo / RTMI — the per-procedure frame record

Every procedure carries a small fixed record the runtime calls RTMI (vbdec: ProcDscInfo), placed immediately after its p-code body — so code start = RTMI − cbCode. The runtime keeps the RTMI pointer in ebx through the prolog and uses it for stdcall cleanup, frame allocation, Erl line lookup, Resume, and destroying the frame's locals on exit. (Full field reference: RTMI_FIELDS.md — derived from the 1998 MSVBVM60 symbols plus compile-diff probes.)

Binary reuse. To relocate and re-run a single p-code function outside its binary (David Zimmer's Binary reuse of VB6 P-code functions), you patch RTMI.pObjectInfo (+0x00) to your own object-info, rebuild the function's constant pool, and enter through the runtime's ProcCallEngine with the ProcDscInfo address in EDX — after initializing the runtime via CreateIExprSrvObj (ThunRTMain works but misbehaves on teardown). A missing return type defaults to a COM Variant the caller must push; simple numeric returns come back in EAX; module globals need codeObj.aModulePublic pointed at writable memory.

Record (UDT) descriptors & RESDESCTBL — one grammar, four uses

VB6 uses a single binary format for every list of “things that need construction, destruction or marshalling at known offsets.” A UDT's record descriptor, a module's data table, a class/form instance table, and a procedure's frame table are all the same structure — the runtime's ConstructItem / DestructItem walk the same entry list. (Full spec incl. the SAFEARRAY template, the ANSI translation layout, the Put/Get file-serialization program and external-typelib record blocks: UDT_DESCRIPTORS.md.)

Header (12 bytes)

flags: 0x01 (frame tables) first entry is the function return value, skipped by teardown; 0x04 always set on record descriptors; 0x08 has members needing destruction (String/Variant/ Object/dynamic array/nested-record-needing-it); 0x10 has an ANSI translation table; 0x20 contains string data. Examples: 0x04 plain UDT, 0x0C Variant/Object, 0x2C String, 0x34 fixed-length strings.

Entries

Packed with no padding, in declaration order (frame tables unsorted). Every entry starts u16 off, u16 type, then type-dependent fields. Type codes (low 5 bits = base type, higher bits = modifiers):

What consumes it

Plain UDTs (no refs, no strings) are copied with CopyBytes — the descriptor is emitted but nothing in p-code references it. Real-world check: all 647 descriptor tables in a 516 KB production binary (PDFStreamDumper) decode to exactly their declared size, independent VB and Python decoders agreeing on every one.

The constant pool

This one trips people up, so it's worth being precise. Each compilation unit (module, class, form) has one constant pool, shared by all of that unit's procedures and built as the compiler walks the file. It is a flat array of DWORD slots at ObjectInfo.lpConstantPool (+0x34), iConstantsCount (+0x28) entries long (iMaxConstants +0x2A reserved). P-code operands index it by slot number: a string load points at a BSTR slot, an ImpAdCall* calls through a native-stub slot, a record op points at a descriptor slot, and so on.

The catch: a slot is just a DWORD. Its meaning comes entirely from what it points at and which opcode uses it — there is no type tag. vbdec classifies each slot by probing its target (Explore → Constant Pool):

Why it matters — binary reuse. To re-run a p-code function outside its binary you must rebuild its unit's pool: real BSTRs via SysAllocString, &guid byte arrays, COMDEF structs, API stubs, and codeobject bases — then point the function's RTMI unit at it. vbdec's Constant Pool viewer will even emit the C or VB rebuild code (constPool[N] = (int)SysAllocString(L"…"), &guid_N, the COMDEF setup) to bootstrap exactly that.

Native thunks (method-link stubs)

Even a pure P-code VB6 exe is full of tiny hand-rolled x86 stubs in .text. They are the glue that lets native call sites — the vtable, AddressOf callbacks, event sinks, the PE import table, Declares — jump into the P-code engine (or an API). vbdec lists them under Explore → Native Stubs (frmNativeStubs); each is a CNativeStub with a VA, owning code object, type, and the target it resolves to. (These are the general case of the VB5 method-link thunks.)

Canonical shapes

The operands are the per-stub target VA and the runtime engine entry (e.g. MethCallEngine / ProcCallEngine):

P-code method (form/class):  33 C0            xor eax, eax
                             BA <ProcDscInfo> mov edx, <target>
                             68 <engine>      push <MethCallEngine>
                             C3               ret
P-code method (module):      BA <ProcDscInfo> mov edx, <target>
                             B9 <engine>      mov ecx, <engine>
                             FF E1            jmp ecx
Event thunk (multiplexed):   B8 <idx>         mov eax, <event index>     ; see gotcha
                             66 3D C0 33      cmp ax, 0C033h
                             BA <target>      mov edx, <target>
                             68 <engine>      push <engine>
                             C3               ret
API Declare / import jump:   FF 25 / jmp dword ptr [import]  (or a push+jmp stub into the API)

Types — and where vbdec recovers each

CNativeStub also carries memOffset (ObjPtr()+memOffset for setEvent/propNewObj/property), the owner code object, and the CMethodLink it came from.

Live memory: reading a running VB6 process

Every structure above also exists in the running process — and reading them live (via ReadProcessMemory, or in-process over the ROT) unlocks what the file can't give you: the instances that actually exist, their data member values, reference counts, and (on VB5) the runtime-filled lpMethods. This is what vbdec's Live Classes / Live Memory viewers do. Three moves cover most of it. (Background: David Zimmer's VB6 Variable Initialization and Teardown; the ROT plumbing is CRemotelyScriptable.cls.)

1 — From a live instance back to the whole object model

A VB6 object reference is a pointer; the ObjectInfo pointer sits one DWORD before the vtable, so from any live ObjPtr you can climb all the way back to the ObjectTable:

p        = ObjPtr(obj)            ' the instance address
pVtbl    = [p]                    ' +0x00 : the vtable pointer
pObjInfo = [pVtbl - 4]            ' the ObjectInfo for this class (stored just before the vtable)
pTObject = [pObjInfo + 0x18]      ' ObjectInfo.aObject  -> this class's tObject (Object descriptor)
pObjTable= [pObjInfo + 0x04]      ' ObjectInfo.aObjectTable -> the project ObjectTable

The tObject descriptor (the lpObjectArray entries, stride 0x30) carries the runtime names and flags: +0x18 aObjectName, +0x1C ProcCount, +0x20 aProcNamesArray (the public method-name strings; a null entry = a private proc), +0x28 ObjectType flags.

2 — Enumerate live instances and walk their data members

Each class's run-time instance manager (RUN_INSTMGR) is reachable from its (static) ObjectInfo. This is the runtime's own list — the same linked list RcmResetModulesPrepass/ExecuteInitTerm walk at shutdown to tear every instance down — so enumerating it finds every live object:

pRunMgr  = [ ObjectInfo.lpProjectData ]   ' lpProjectData = ObjectInfo + 0x1C
count    = [ pRunMgr + 0x0C ]             ' how many live instances
objPtr   = [ pRunMgr + 0x00 ]             ' first instance
'   per instance:  refCount = [objPtr + 0x20] ;  nextInstance = [objPtr + 0x04]

Then each public variable's value lives at objPtr + PubVarDesc.dataOffset, read according to the descriptor's base type:

Module-level / static variables work the same but their dataOffset is an absolute address, not objPtr-relative. (This is the same PubVarDesc.dataOffset the field annotator uses — static type info + a live pointer = typed, named member values.)

3 — Private variables & resource teardown (RESDESCTBL)

The IDispatch descriptors above cover only public members. Private module/class variables that require cleanup are described by a second structure the runtime uses for init and tear-down: RESDESCTBL, pointed to by Object.aPublicBytes. It exists so a terminating object can free its strings/objects/arrays (RESDESCTBL::DestructItem) and so pre-dimensioned arrays are ready on first use (RESDESCTBL::ConstructItem).

Header (tResDescTbl): size, memDataSz (end-marker of the class data block, 0xABABABAB), reqAlloc, entries, unk1 — followed by per-variable entries of { dataOffset, typeId } (e.g. typeId 1 = String, 3 = Object; it also tracks Variants, Arrays and UDTs whose subtype needs cleanup). For instanced objects the member is at ObjPtr + dataOffset; for BAS modules the data lives at Object.aModulePublic (absolute). Pre-dimensioned array (SafeArray) definitions live here too.

4 — Make a class public and reach it over the ROT

Normally only forms/public objects are externally reachable. You can flip a private class in memory by setting bit 0x800 in its tObject.objectType (+0x28), then register the instance in the Running Object Table so a script can GetObject it:

' per class: locate tObject (via the chain above, or walk ObjectTable.lpObjectArray [+0x30], stride 0x30,
' count at +0x2A), then:
VirtualProtect va+0x28, 4, PAGE_EXECUTE_READWRITE, old
PutMem4 va+0x28, objectType Xor 0x800          ' set the "public" bit
VirtualProtect ... restore
' then publish it:
GetRunningObjectTable 0, pROT
CreateFileMoniker StrPtr("myapp.obj"), pMoniker
pROT.Register ROTFLAGS_REGISTRATIONKEEPSALIVE, ObjPtr(obj), ObjPtr(pMoniker), VarPtr(cookie)
'   -> a client does:  Set o = GetObject("myapp.obj")

Reads/writes use the undocumented MSVBVM60 helpers GetMem4/PutMem4 (and CopyMemory); verify the target really is a VB6 object first (__vbaCheckType with the VB6 object IID). This is exactly how vbdec exposes vbdec.frmMain/vbdec.vbp for the ROT automation used throughout these tools.

Gotchas & version notes (quick reference)

• VB5 vs VB6 is a minor delta. Same VB5! signature, same structures, same opcode set (VB6 only appends). The one real structural change is where a method's code-descriptor VA lives (ObjectInfo.lpMethods flat array in VB6 vs mov edx,<ProcDscInfo> method-link thunks in VB5). Full detail in the opcode reference's VB5 vs VB6 section.
• P-code vs native share every structure here. Differences: ProjectInfo.aNativeCode is set for native; ObjectInfo.NumberOfProcs counts user procs + API declares for P-code but API declares only for native; per-method bodies are P-code vs x86.
• Offsets vs pointers. a* fields are absolute VAs; o* fields are offsets relative to a base (usually the owning struct's VA). Mixing them up lands you in the weeds.
• Recompile churn to ignore in diffs: all per-object GUIDs and the project/object CLSIDs regenerate every build; ProjectInfo.OriginalPathName reflects only the build machine; most VAs shift.
• Deeper layers (not repeated here): per-procedure ProcDscInfo/RTMI frame tables, UDT/record descriptors, the control property blob grammar, and events each have their own companion write-up.

Generated from structs_sample.txt + the vbdec struct sources. This documents the structures as vbdec parses them; field names follow vbdec's naming, which in turn builds on the VB-reversing community's decades of work on the format.

Runtime symbol reference (MSVBVM60)

Jump-off points for your own reversing. Addresses are in the symboled MSVBVM60.DLL v6.00.8268 (linked 1998-09-26, imagebase 0x66000000) — the same build vbdec ships as its target.runtime; names are the runtime's own (C++-mangled in the DLL, shown demangled). Offsets drift between builds, so match by name.

Control & property load

Records / RESDESCTBL / UDT

Procedure / RTMI, instance teardown, scaling

Structures named by these routines: CTL, FILEREF, tagPROP, tagCTLHDR, Projitem / Project, RTMI, RESDESCTBL / RESDESC, RUN_INSTMGR. Pair with a stock-symbol MSVBVM60.DLL (or vbdec's target.runtime) in IDA to follow them live.

Credits

This reference was created by David Zimmer (sandsprite.com), working with Claude (Anthropic).

On the shoulders of others

None of this starts from zero. This reference stands on the shoulders of several generations of VB reversers, who mapped the runtime, the file format and the P-code engine long before AI tools existed, and who shared what they found.

Credits include the VB Decompiling community, Sarge, Napalm, VbGamer45, Mr. Unleaded, Moogman, _aLfa_, Alex Ionescu, Warning, josephCo, Darker, Trick, Firehacker, dodi, sysenter-eip and others.

Special thanks go out to:

• VbGamer45 for his work on Semi VB Decompiler
• Mr. Unleaded for allowing the old forums to be rebuilt
• Mr Silver and Mr Snow for their excellent work on the WKTVBDebugger
• Darker for his excellent work on p32Dasm
• Reginald Wong for his vb.idc script
• The OG wizards who created VB6