DotPeek not generating pdb

Hello,

I have a dll that I'm trying to decompile and put break points in. I'm trying to use DotPeek to do so. So I right-click on the dll and select "Generate Pdb...". It the log, it shows up with a warning symbol and if I hover over the warning symbol it says "Pdb has not been generated because assembly does not contain debug directory'.

Can anyone please help explain what this means and how to fix it?

 

Thank you.

0
7 comments
Official comment

Hello,

Do you use standalone dotPeek, or the Decompiler functionality built-in in ReSharper?

Anyways, generally speaking, following this guide should help to configure the environment for debugging decompiled sources: https://www.jetbrains.com/help/decompiler/10.0/Using_product_as_a_Symbol_Server.html?origin=old_help

Let me know how it goes. Thanks!

Avatar
Permanently deleted user

I am having the same issue.

Using dotPeek 2016.1 as symbol server. It works for most assemblies but for some it fails with error: "Pdb has not been generated because assembly does not contain debug directory". Trying to manually generate pdb in dotPeek fails as well. However decompilation inside dotPeek works - it is just pdb generation that fails.

The comments above do not really answer the original question:

  • why does pdb generation fail if assembly does not contain debug directory?
  • is there a workaround?

Thanks

2
Avatar
Permanently deleted user

Same problem. It works OK, but for some 3rd party fails with this error.  What do we do?

1
Avatar
Permanently deleted user

Agreed with above.  Question not answered.

1

Hello everyone,

Please refer to the comments section of this issue: https://youtrack.jetbrains.com/issue/DOTP-6889

VS Debugger can not associate generated pdb (and any other pdb) and this assembly because this assembly does not contain debug directory (and therefore assembly does not contain pdb GUID).

A quote from here:
"When you load a module into the process address space, the debugger uses two pieces of information to find the matching PDB file. The first is obviously the name of the file. If you load ZZZ.DLL, the debugger looks for ZZZ.PDB. The extremely important part is how the debugger knows this is the exact matching PDB file for this binary. That’s done through a GUID that’s embedded in both the PDB file and the binary. If the GUID does not match, you certainly won’t debug the module at the source code level."

Thanks!

0
Avatar
Permanently deleted user

So, what you are saying is that the Debug Directory value of the PE header is actually the GUID? Then it makes sense to me. Unfortunate, but makes sense.

0

Please sign in to leave a comment.