WinDbg find all C++ objects of type X on heap that do not use inheritance (no vftable)

Question

I have a C++ application with debug symbols, and created a dump file of such application with all relevant gflags enabled:

gflags /i xxx.exe +hpa
gflags /i xxx.exe +ust

Now, I have found from other questions (see here), that by first looking for a type's vftable address:

x module!SomeClass*table*

And then searching the heap for that address:

!heap -srch 'address_of_vtable'

I can find all instances of that type. That is true, if the vftable exists for such type.

From what I have read, the vftable is only created for types that use inheritance, but if a type does not use inhertance at all, then it does not get created.

If the vftable is not created then the approach above does not seem to work. I can find an address for the type using (no vftable):

 x module!SomeClass::SomeClass

But if I search the heap for the returned address, there are no matches, eventhough I know I have several instances of such type.

What other people have done is to force the creation of the vftable, but modifying the code base in such a way for the sake of debugging does not seem like a good or practical approach for existing large code bases.

Is there a way, combination of windbg commands, to look for instances of a (non-inheritance) type in a dump file without having to modify the source code?

NOTE : I know there are other tools for heap analysis, like umdh and heap snapshots with WPR, but I assume I only have a regular, full, good old-fashined dump. All the heap information is in that dump, have the symbols and sources, so there must be a way, right?

Answer 1

Given that an object can be created out of random bytes (so long as alignment requirements are met) it is impossible to say whether some random collection of bytes is of any particular type. Even in the case where there is a value that matches a vtable pointer that is only a very strong hint rather than conclusive proof. After all it would be possible to have an integral member that just happens to have a value that matches the address of a vtable for whatever reason.

Given that reality, I would say it is impossible to even guess at the type of a collction of bytes that do not have a vtable-matching value.