[pdb] Chrome.pdb file for v122 can't be processed to be strippeddown by pdbcopy.exe

[IDA-RE-things]

I'm trying to create "stripped down" PDB, (without type information) from original chrome.dll.pdb. which is now 1.8 Gig., and uses nonstandard 8k pages inside.

To be able to load it into VS2008 etc tools, including ProcessExplorer, or profilers, running on XP.

I'm using pdbcopy.exe from MS "Debugging Tools for Windows" package with -p switch.
Trying this tools even from [WinSDK_10.0.10586.212],
even x64 version of it, and running on Win7 x64

• For PDB of Chrome.dll v121 it works ok and creates proper PDB file with size near 200mb, Which I succesfully loaded then by VS to debug.
• But for PDB of Chrome.dll v122 -- pdbcopy returns with unknown error after some time of processing.

I'm understand of course that this is not your problem, but problem of MS tools.
But what you have changed beetween this 2 builds ?

[IDA-RE-things]

@win32ss , Can you run this command also on you build machine ?
I mean :
pdbcopy.exe chrome.dll.pdb chrome.dll.stripped.pdb -p

And provide this stripped-down PDB in the released symbols package also, if this succeeded to process.

Also you can use additional linker flag /pdbstripped:filename to make such pdb while linking, additionally to full PDB.
May be this will help

[win32ss]

@win32ss , Can you run this command also on you build machine ? I mean : pdbcopy.exe chrome.dll.pdb chrome.dll.stripped.pdb -p

And provide this stripped-down PDB in the released symbols package also, if this succeeded to process.

Also you can use additional linker flag /pdbstripped:filename to make such pdb while linking, additionally to full PDB. May be this will help

I did it using pdbcopy version 14.30.30795. However it only creates PDBs with a size of about 5 MB and the only information in them refers to some obj and lib files and no actual names, just like the "sham" nvlddmkm symbols I have found in some Windows symbol packages.

I have not found any changes to debugging flags recently. Another possible option is to use the internal symbol level 0 (as opposed to symbol level 1) which produced the ~200 MB pdbs in the past, but I am not sure if they will now.

[IDA-RE-things]

@win32ss, In anycase MS itself do it somehow for its MS Edge browser. I have seen that pdb.

try /PDBSTRIPPED switch for linker.

[win32ss]

I tried to find a solution that did not trigger a 80% rebuild of the browser, but the PDB stripping switches did not have an effect because of the conflicting symbol level switches I set previously. So I switched to symbol level 0 which needed a considerable rebuild.

[IDA-RE-things]

/pdbstripped:filename is only linker switch.
It create stripped pdb file additionally to full pdb. And must not touch already compiled object files.

What is "symbol level switches" ?, its something new for new VisualStudios ? I have not seen this from VS6 to VS2015.

Then we must use some compatible-level, or "standard", or so on. So it will generate symbols, compatible with other tools.

[win32ss]

lld is Chromium's linker (optimizations don't allow the use of the MSVC linker) and it does not support /PDBSTRIPPED.

The switches in the Chromium build config files I was referring to, directly control the level of debugging information in the PDBs. And from previous experience, symbol level 0 is similar to the stripped symbols pdbcopy used to produce, at least in file size.

[IDA-RE-things]

Thats news for me. Earler versions in past was linked with native MSVC linker.
Though they was small in size, not 200 Mb.

UPD:
As I have found Chromium was switched to lld linker with clang as default. At some time (~2018).

So you think MS itself uses lld linker and clang instead of own linker and compiler in their today builds of Edge ? (2017-2024 y)

[win32ss]

So you think MS itself uses lld linker and clang instead of own linker and compiler in their today builds of Edge ? (2017-2024 y)

Edge does use LLD. I just found a copy of Edge 114 and found the signature "LLD PDB" in edge.exe, just above a string with the path of the PDB on the build volume.

[IDA-RE-things]

Yes, I have checked also. its LLD PDB.

But nevertheless, they somehow got this PDB (even using LLD). with adequate size ~350 Mb.
Because it has no type information and so on.

Another possible option is to use the internal symbol level 0 (as opposed to symbol level 1) which produced the ~200 MB pdbs in the past, but I am not sure if they will now.

As that, this is that switch. Which results we have now with it ?
It needs to fully rebuild whole project to have full pdb and that "small" pdb ? Thats bad of cource.

[win32ss]

Down to 600 MB with main symbol level 0.

[IDA-RE-things]

600 MB -- Ok.
This may work.
Can you upload it so I will try and test ?

[win32ss]

I have now uploaded the PDB and corresponding chrome.dll (which can replace the existing one).

[IDA-RE-things]

UPD: uploaded Pdb working now (partly),
I can see the CallStack.
But VS2008 dont resolves linenumbers info for it (while it has inside).
While for Chrome.exe -- VS2008 does it and shows file/linenumber. Meanwhile it was created with same tools (LLD/Clang).
Now I'm trying remote debug from Win7 machine using VS2010. (Remote tools from later VS releases wan't de installed on XP. Fucking MS done all possible to drop XP out ).

Not closing this ticket while.

[IDA-RE-things]

UPD: BTW, pdbcopy for this 600 Mb file, fails with same strange error, as before:

"Error: EC_OK"
:))
like "Error : All Right"
And result PDB has no proper info, or info at all.

I close this ticket while.
And continue in fixing of AccessViolation .. #355