Pdb & elf both follow the DWARF format, so is it possible to support ELF files？

• error 1

  • original

  struct Struct1
  {
      uint16 filed_1 : 1;
      uint16 filed_2 : 5;
      uint16 filed_3 : 10;
  };

  • PDBRipper output

  struct Struct1
  {
      unsigned int filed_1:1;
      unsigned int filed_2:5;
      unsigned int filed_3:10;
  };
  

• error 2

  • original

  struct Struct2
  {
      union {
    	  uint16 filed_1 : 1;
    	  uint16 filed_2 : 5;
    	  uint16 filed_3 : 10;
      };
  };
  

  • PDBRipper output

  struct Struct2
  {
      unsigned int filed_1:1;
      unsigned int filed_2:5;
      unsigned int filed_3:10;
  };
  

• error 3

  • original

  union Struct4 {
      struct
      {
    	  uint16 filed_1 : 1;
    	  uint16 filed_2 : 5;
    	  uint16 filed_3 : 10;
      };
  
  };
  

  • PDBRipper output

  union Struct4
  {
      unsigned int filed_1:1;
      unsigned int filed_2:5;
      unsigned int filed_3:10;
  };
  

they have completely different meanings

see assembly output here

Hi horsicq !

1. wrong size=8 integer type fix, not all "int/long" combinations covered
   if(pHandleOptions->bFixTypes)
   {
   if((result.nBaseType==7) &&(result.nSize!=4)) // "unsigned int"
   {
   switch(result.nSize)
   {
   case 1: result.sTypeName="unsigned char"; break;
   case 2: result.sTypeName="unsigned short"; break;
   case 4: result.sTypeName="unsigned int"; break;
   case 8: result.sTypeName="unsigned long"; break;
   }
   }

supposed to be :
if(pHandleOptions->bFixTypes)
{
if((result.nBaseType==7 || result.nBaseType==14) &&(result.nSize!=4)) // "unsigned int"
{
switch(result.nSize)
{
case 1: result.sTypeName="unsigned char"; break;
case 2: result.sTypeName="unsigned short"; break;
case 4: result.sTypeName="unsigned int"; break;
case 8: result.sTypeName="unsigned long long"; break; // or __int64
}
}
if((result.nBaseType==6 || result.nBaseType==13) &&(result.nSize!=4)) // "int"
{
switch(result.nSize)
{
case 1: result.sTypeName="char"; break;
case 2: result.sTypeName="short"; break;
case 4: result.sTypeName="int"; break;
case 8: result.sTypeName="long long"; break;
}
}
}

2. in void QWinPDB::_appendElem()
   _dwSize+= pListChildren->at(j).dwSize;
   to:
   if (pListChildren->at(j).dwBitOffset) {
   _dwSize+= 0;
   } else {
   _dwSize+= pListChildren->at(j).dwSize;
   }

this need for unions with child bitsized fields to avoid increment total size
example:
struct _EX_PUSH_LOCK// Size=0x4
{
union // Size=0xc
{
struct // Size=[b]0xc[/b] - wrong, next fields after this internal struct will be assume at offset 0xc
{
unsigned long Waiting:1;// Offset=0x0 Size=0x4 BitOffset=0x0 BitSize=0x1
unsigned long Exclusive:1;// Offset=0x0 Size=0x4 BitOffset=0x1 BitSize=0x1
unsigned long Shared:30;// Offset=0x0 Size=0x4 BitOffset=0x2 BitSize=0x1e
};
unsigned long Value;// Offset=0x0 Size=0x4
void *Ptr;// Offset=0x0 Size=0x4
};
};

3. union/fields "fix engine" still has bugs:
   unsigned long GrantedAccess;// Offset=0x23c Size=0x4
   union // Size=0x4
   {
   unsigned long CrossThreadFlags;// Offset=0x240 Size=0x4
   unsigned long Terminated:1;// Offset=0x240 Size=0x4 BitOffset=0x0 BitSize=0x1
   };
   unsigned long DeadThread:1;// Offset=0x240 Size=0x4 BitOffset=0x1 BitSize=0x1 - outside of union
   unsigned long HideFromDebugger:1;// Offset=0x240 Size=0x4 BitOffset=0x2 BitSize=0x1
   unsigned long ActiveImpersonationInfo:1;// Offset=0x240 Size=0x4 BitOffset=0x3 BitSize=0x1
   unsigned long SystemThread:1;// Offset=0x240 Size=0x4 BitOffset=0x4 BitSize=0x1
   unsigned long HardErrorsAreDisabled:1;// Offset=0x240 Size=0x4 BitOffset=0x5 BitSize=0x1
   unsigned long BreakOnTermination:1;// Offset=0x240 Size=0x4 BitOffset=0x6 BitSize=0x1
   unsigned long SkipCreationMsg:1;// Offset=0x240 Size=0x4 BitOffset=0x7 BitSize=0x1
   unsigned long SkipTerminationMsg:1;// Offset=0x240 Size=0x4 BitOffset=0x8 BitSize=0x1

The command line and GUI version both crash when trying to export to c++. No error messages are displayed and no output is saved.

Command used: pdbripperc.exe -o head.h -d -s -p -c MYPDB.pdb

Screenshot of last verbose before crash/close

Layout of "activity_level_instance_base"
class activity_level_instance_base { /* 0x0000 */ long Padding_2132[6]; /* 0x0018 */ class activity_instance_base* m_instance; /* 0x0020 */ unsigned int cash_award; /* 0x0024 */ unsigned int respect_award; }; /* size: 0x0028 */

You use:

    HRESULT hr=NoRegCoCreate(L"msdia140.dll", _uuidof(DiaSourceAlt),
                              _uuidof(IDiaDataSource),
                              (void **)(&g_pDiaDataSource));

But this crashes (in Debug mode) because DiaSourceAlt uses a different string allocation strategy and SysFreeString will cause heap corruption. If you want to use DiaSourceAlt you have to use LocalFree(bstr - 2) (completely undocumented except for a wrong hint at https://www.developerfusion.com/article/84368/debugging-with-the-dia-sdk/)

In the past I did some benchmarks and using DiaSourceAlt isn't faster for loading symbols (source lines or globals) but I don't know about types. How would you prefer to handle this? I can switch to DiaSource or change all SysFreeString to LocalFree.

Great project! Very useful.

However, this project doesn't support unnamed union in struct

If more than one field in a struct shares the same offset, they shoud be in a unnamed union

Could you check why it doesn't show anything when opening this file with v2.0? https://mega.nz/file/G9slAIJR#6o4vEGLEIFZaJpUltIUa2wK-_jAvRAQt9yTuLr6M5qQ

Привет,

возможно пригодятся мои патчи, пофиксены определения вхождения элементов в структуры/юнионы и еще пара мелких улучшений

https://ufile.io/kivrr5gw
состав:
qwinpdb.h
qwinpdb.cpp

результат для Windows 7 x64 ntkrnlmp.exe
http://msdl.microsoft.com/download/symbols/ntkrnlmp.pdb/3844DBB920174967BE7AA4A2C20430FA2/ntkrnlmp.pdb
w7_x64_ntkrnlmp.pdb.h

результат для Windows XP x64 ntkrnlmp.exe
http://msdl.microsoft.com/download/symbols/ntkrnlmp.pdb/03185083233249D9BB747EA777B80C982/ntkrnlmp.pdb
xp_x64_ntkrnlmp.pdb.h

Seems to be a common issue for a lot of pdb tools, i would think proper types are in the pdb tho.. They are at least in the mangled name

I tried dumping a PDB from TitanHide. It looks like the option to dump C/C++ headers with type dependencies doesn’t actually allow me to compile a program that includes those headers.

and support for the compiler to compile successfully, may refer to: this

The XNTSV output has incorrect names and types for function pointers.

                {
                    "name": "OpenRoutine)(union _LARGE_INTEGER )",
                    "offset": 56,
                    "size": 8,
                    "type": "unsigned char  ( *"
                }

An example function pointer members from _DUMP_INITIALIZATION_CONTEXT. Ideally name would be OpenRoutine, and type would be unsigned char ( * )(union _LARGE_INTEGER ).

Is there a way to produce a map file from a pdb?
Pdb file has all function names in it but there is a signature problem or somethingelse idk. I just want to extract all function names from it

The PDB format uses pseudo and compgenx flags to specify these functions
https://github.com/microsoft/microsoft-pdb/blob/master/include/cvinfo.h#L1145
for example public: void __dflt_ctor_closure(); is one such function but there are less obvious ones like copy ctors, copy operators and other things that are not clear if they were actually implemented.

Hey!

When I'm trying to export symbols from a PDB that contains names that are invalid file names on Windows, the files are getting skipped, but the output JSON file says they are there:

  "infofile": "class std::map<int,float,std::less<int>,std::allocator<std::pair<int const ,float> > >.txt",
  "name": "class std::map<int,float,std::less<int>,std::allocator<std::pair<int const ,float> > >",
  "positions": [
    {
      "name": "",
      "offset": 0,
      "size": 0,
      "type": ""
    },
    ...

In reality, that file is not created.
Windows file naming information: https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file

File name sanitization is required before saving.

suas as MyClass, std::vector<MyClass> ....,
MyClass should always appear on the first line