Does signing a DLL invalidate a PDB file?WinDbg Dr. Watson minidump - requires pdb/dll originally built for installed version?PDB file crashdump user.dmpHow can you change an age-mismatched PDB to match properly?Symbols (pdb) for native dll are not loaded due to post build stepRelease generating .pdb files, why?looking for java .pdb files, analyze a crash hdmp fileCrash dump - WinDbg - force PDB files to match doesn't work?Debugging MFC: “mfc100.dll” cannot find or open pdbExtracting structure information from pdbs of unloaded modulesHow do I get the symbols for a single DLL without having a dump?
Are there any of the Children of the Forest left, or are they extinct?
Adding command shortcuts to bin
PWM 1Hz on solid state relay
How to increase the size of the cursor in Lubuntu 19.04?
How do LIGO and VIRGO know that a gravitational wave has its origin in a neutron star or a black hole?
IP addresses from public IP block in my LAN
Should I dumb down my writing in a foreign country?
Why do people keep telling me that I am a bad photographer?
Can FreeNAS zfs send to a Linux machine?
Appropriate certificate to ask for a fibre installation (ANSI/TIA-568.3-D?)
What exactly are the `size issues' preventing formation of presheaves being a left adjoint to some forgetful functor?
What is a smasher?
What was Bran's plan to kill the Night King?
How to safely wipe a USB flash drive
Manager is threatening to grade me poorly if I don't complete the project
Pressure inside an infinite ocean?
Would glacier 'trees' be plausible?
Where are the "shires" in the UK?
Floor of Riemann zeta function
How long would it take for people to notice a mass disappearance?
Where in Bitcoin Core does it do X?
Does it make sense for a function to return an rvalue reference?
Copy previous line to current line from text file
Causes of bimodal distributions when bootstrapping a meta-analysis model
Does signing a DLL invalidate a PDB file?
WinDbg Dr. Watson minidump - requires pdb/dll originally built for installed version?PDB file crashdump user.dmpHow can you change an age-mismatched PDB to match properly?Symbols (pdb) for native dll are not loaded due to post build stepRelease generating .pdb files, why?looking for java .pdb files, analyze a crash hdmp fileCrash dump - WinDbg - force PDB files to match doesn't work?Debugging MFC: “mfc100.dll” cannot find or open pdbExtracting structure information from pdbs of unloaded modulesHow do I get the symbols for a single DLL without having a dump?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
Analyzing a crash dump, WinDbg says my symbols (PDB file) does not match the module. The symbols are the ones generated when the DLL was compiled. The only thing that I can imagine would cause a mismatch is that the DLL was signed.
I'm using !chksym to validate symbols:
!chksym libcef.dll D:symlibcef.dll.pdb
libcef.dll
Timestamp: 5BB3D477
SizeOfImage: 626D000
pdb: F:srcoutlibcef.dll.pdb
pdb sig: B0065D83-113F-63BE-53BC-AEF07EC816B4
age: 1
libcef.dll.pdb
pdb sig: 9BA88A40-D168-44F2-44C1-DD2D73A38B38
age: 1
sig MISMATCH: libcef.dll.pdb and libcef.dll
windbg debug-symbols pdb-files
asked Mar 22 at 23:55
kiewickiewic
10.5k96176
add a comment |
Analyzing a crash dump, WinDbg says my symbols (PDB file) does not match the module. The symbols are the ones generated when the DLL was compiled. The only thing that I can imagine would cause a mismatch is that the DLL was signed.
I'm using !chksym to validate symbols:
!chksym libcef.dll D:symlibcef.dll.pdb
libcef.dll
Timestamp: 5BB3D477
SizeOfImage: 626D000
pdb: F:srcoutlibcef.dll.pdb
pdb sig: B0065D83-113F-63BE-53BC-AEF07EC816B4
age: 1
libcef.dll.pdb
pdb sig: 9BA88A40-D168-44F2-44C1-DD2D73A38B38
age: 1
sig MISMATCH: libcef.dll.pdb and libcef.dll
windbg debug-symbols pdb-files
asked Mar 22 at 23:55
kiewickiewic
10.5k96176
1
With Signing you mean Authenticode signing? I am not aware that this changes the debug header. It more looks like you did recompile the dll from the same sources. You can force a load with .reload -f -i libcef.dll if you symbol path contains the directory where your new pdb is located. Use .sympath+ F:srcout to add it. Then debugging should be a non issue.
– Alois Kraus
Mar 23 at 0:10
@AloisKraus Yes, authenticode signing. Force reload seems to work fine. I'm more concern if I may be debugging wrong stuff because of symbol mismatch. Do you how can I look at the debug header?
– kiewic
Mar 23 at 0:36
I notice your pdb has a .dll appended to it afaik vc creates pdb with the .dll stripped ie it creates a libcef.pdb instead of libcef.dll.pdb do you have a -Fxyz switch passed on that provides a different name for pdb in your projects ? no signing afaik doesn't change anything inside your binary (imagine ms embedding an oops backdoor if it does that cant it ? ) use dumpbin /headers to check the path embedded inside binary
– blabb
Mar 23 at 8:18
add a comment |
Analyzing a crash dump, WinDbg says my symbols (PDB file) does not match the module. The symbols are the ones generated when the DLL was compiled. The only thing that I can imagine would cause a mismatch is that the DLL was signed.
I'm using !chksym to validate symbols:
!chksym libcef.dll D:symlibcef.dll.pdb
libcef.dll
Timestamp: 5BB3D477
SizeOfImage: 626D000
pdb: F:srcoutlibcef.dll.pdb
pdb sig: B0065D83-113F-63BE-53BC-AEF07EC816B4
age: 1
libcef.dll.pdb
pdb sig: 9BA88A40-D168-44F2-44C1-DD2D73A38B38
age: 1
sig MISMATCH: libcef.dll.pdb and libcef.dll
windbg debug-symbols pdb-files
asked Mar 22 at 23:55
kiewickiewic
10.5k96176
Analyzing a crash dump, WinDbg says my symbols (PDB file) does not match the module. The symbols are the ones generated when the DLL was compiled. The only thing that I can imagine would cause a mismatch is that the DLL was signed.
I'm using !chksym to validate symbols:
!chksym libcef.dll D:symlibcef.dll.pdb
libcef.dll
Timestamp: 5BB3D477
SizeOfImage: 626D000
pdb: F:srcoutlibcef.dll.pdb
pdb sig: B0065D83-113F-63BE-53BC-AEF07EC816B4
age: 1
libcef.dll.pdb
pdb sig: 9BA88A40-D168-44F2-44C1-DD2D73A38B38
age: 1
sig MISMATCH: libcef.dll.pdb and libcef.dll
windbg debug-symbols pdb-files
windbg debug-symbols pdb-files
asked Mar 22 at 23:55
kiewickiewic
10.5k96176
asked Mar 22 at 23:55
kiewickiewic
10.5k96176
asked Mar 22 at 23:55
kiewickiewic
10.5k96176
asked Mar 22 at 23:55
kiewickiewic
10.5k96176
asked Mar 22 at 23:55
kiewickiewic
10.5k96176
10.5k96176
1
With Signing you mean Authenticode signing? I am not aware that this changes the debug header. It more looks like you did recompile the dll from the same sources. You can force a load with .reload -f -i libcef.dll if you symbol path contains the directory where your new pdb is located. Use .sympath+ F:srcout to add it. Then debugging should be a non issue.
– Alois Kraus
Mar 23 at 0:10
@AloisKraus Yes, authenticode signing. Force reload seems to work fine. I'm more concern if I may be debugging wrong stuff because of symbol mismatch. Do you how can I look at the debug header?
– kiewic
Mar 23 at 0:36
I notice your pdb has a .dll appended to it afaik vc creates pdb with the .dll stripped ie it creates a libcef.pdb instead of libcef.dll.pdb do you have a -Fxyz switch passed on that provides a different name for pdb in your projects ? no signing afaik doesn't change anything inside your binary (imagine ms embedding an oops backdoor if it does that cant it ? ) use dumpbin /headers to check the path embedded inside binary
– blabb
Mar 23 at 8:18
add a comment |
1
With Signing you mean Authenticode signing? I am not aware that this changes the debug header. It more looks like you did recompile the dll from the same sources. You can force a load with .reload -f -i libcef.dll if you symbol path contains the directory where your new pdb is located. Use .sympath+ F:srcout to add it. Then debugging should be a non issue.
– Alois Kraus
Mar 23 at 0:10
@AloisKraus Yes, authenticode signing. Force reload seems to work fine. I'm more concern if I may be debugging wrong stuff because of symbol mismatch. Do you how can I look at the debug header?
– kiewic
Mar 23 at 0:36
I notice your pdb has a .dll appended to it afaik vc creates pdb with the .dll stripped ie it creates a libcef.pdb instead of libcef.dll.pdb do you have a -Fxyz switch passed on that provides a different name for pdb in your projects ? no signing afaik doesn't change anything inside your binary (imagine ms embedding an oops backdoor if it does that cant it ? ) use dumpbin /headers to check the path embedded inside binary
– blabb
Mar 23 at 8:18
1
1
With Signing you mean Authenticode signing? I am not aware that this changes the debug header. It more looks like you did recompile the dll from the same sources. You can force a load with .reload -f -i libcef.dll if you symbol path contains the directory where your new pdb is located. Use .sympath+ F:srcout to add it. Then debugging should be a non issue.
– Alois Kraus
Mar 23 at 0:10
With Signing you mean Authenticode signing? I am not aware that this changes the debug header. It more looks like you did recompile the dll from the same sources. You can force a load with .reload -f -i libcef.dll if you symbol path contains the directory where your new pdb is located. Use .sympath+ F:srcout to add it. Then debugging should be a non issue.
– Alois Kraus
Mar 23 at 0:10
@AloisKraus Yes, authenticode signing. Force reload seems to work fine. I'm more concern if I may be debugging wrong stuff because of symbol mismatch. Do you how can I look at the debug header?
– kiewic
Mar 23 at 0:36
@AloisKraus Yes, authenticode signing. Force reload seems to work fine. I'm more concern if I may be debugging wrong stuff because of symbol mismatch. Do you how can I look at the debug header?
– kiewic
Mar 23 at 0:36
I notice your pdb has a .dll appended to it afaik vc creates pdb with the .dll stripped ie it creates a libcef.pdb instead of libcef.dll.pdb do you have a -Fxyz switch passed on that provides a different name for pdb in your projects ? no signing afaik doesn't change anything inside your binary (imagine ms embedding an oops backdoor if it does that cant it ? ) use dumpbin /headers to check the path embedded inside binary
– blabb
Mar 23 at 8:18
I notice your pdb has a .dll appended to it afaik vc creates pdb with the .dll stripped ie it creates a libcef.pdb instead of libcef.dll.pdb do you have a -Fxyz switch passed on that provides a different name for pdb in your projects ? no signing afaik doesn't change anything inside your binary (imagine ms embedding an oops backdoor if it does that cant it ? ) use dumpbin /headers to check the path embedded inside binary
– blabb
Mar 23 at 8:18
add a comment |
1 Answer
1
active
oldest
votes
Code signing an executable or DLL does not affect the debug header of the executable. Thus, it will still match the PDB.
...SigningPdbbinRelease>symchk signed.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
...SigningPdbbinRelease>symchk unsigned.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
And
...SigningPdbbinRelease>ChkMatch.exe -c signed.exe SigningPdb.pdb
ChkMatch - version 1.0
Copyright (C) 2004 Oleg Starodumov
http://www.debuginfo.com/
Executable: signed.exe
Debug info file: SigningPdb.pdb
Executable:
TimeDateStamp: bc78c18e
Debug info: 2 ( CodeView )
TimeStamp: a7b373e5 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 97 RVA: 000026a0 FileOffset: 000008a0
CodeView format: RSDS
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
PdbFile: ...ReleaseSigningPdb.pdb
Debug info: 16 ( Unknown )
TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 0 RVA: 00000000 FileOffset: 00000000
Debug information file:
Format: PDB 7.00
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
Result: Matched
The timestamp is in the COFF header. That header is only 24 bytes in size and will not change during code signing.
Most changes will happen in a new section for certificates. This section, however, will also be ignored during code signing. Otherwise, a second signature would destroy the first signature. (BTW: this section has been used to transport malicious code inside a signed executable)
Of course, the "usual" checksums, which do not consider the EXE/DLL file structure, will report a different checksum.
What may have happened to your DLL or EXE?
- you have accidentally rebuilt it, so the time stamp of your DLL does not match the PDB any more
- you are using aspect oriented programming (AOP) in .NET and there is some code weaving happening after a rebuild. These tools might not be able to rebuild the PDB after weaving, so the PDB mismatch is already there before the DLL is code signed.
answered Mar 23 at 18:15
Thomas WellerThomas Weller
29.7k1171143
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55309226%2fdoes-signing-a-dll-invalidate-a-pdb-file%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Code signing an executable or DLL does not affect the debug header of the executable. Thus, it will still match the PDB.
...SigningPdbbinRelease>symchk signed.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
...SigningPdbbinRelease>symchk unsigned.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
And
...SigningPdbbinRelease>ChkMatch.exe -c signed.exe SigningPdb.pdb
ChkMatch - version 1.0
Copyright (C) 2004 Oleg Starodumov
http://www.debuginfo.com/
Executable: signed.exe
Debug info file: SigningPdb.pdb
Executable:
TimeDateStamp: bc78c18e
Debug info: 2 ( CodeView )
TimeStamp: a7b373e5 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 97 RVA: 000026a0 FileOffset: 000008a0
CodeView format: RSDS
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
PdbFile: ...ReleaseSigningPdb.pdb
Debug info: 16 ( Unknown )
TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 0 RVA: 00000000 FileOffset: 00000000
Debug information file:
Format: PDB 7.00
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
Result: Matched
The timestamp is in the COFF header. That header is only 24 bytes in size and will not change during code signing.
Most changes will happen in a new section for certificates. This section, however, will also be ignored during code signing. Otherwise, a second signature would destroy the first signature. (BTW: this section has been used to transport malicious code inside a signed executable)
Of course, the "usual" checksums, which do not consider the EXE/DLL file structure, will report a different checksum.
What may have happened to your DLL or EXE?
- you have accidentally rebuilt it, so the time stamp of your DLL does not match the PDB any more
- you are using aspect oriented programming (AOP) in .NET and there is some code weaving happening after a rebuild. These tools might not be able to rebuild the PDB after weaving, so the PDB mismatch is already there before the DLL is code signed.
answered Mar 23 at 18:15
Thomas WellerThomas Weller
29.7k1171143
add a comment |
Code signing an executable or DLL does not affect the debug header of the executable. Thus, it will still match the PDB.
...SigningPdbbinRelease>symchk signed.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
...SigningPdbbinRelease>symchk unsigned.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
And
...SigningPdbbinRelease>ChkMatch.exe -c signed.exe SigningPdb.pdb
ChkMatch - version 1.0
Copyright (C) 2004 Oleg Starodumov
http://www.debuginfo.com/
Executable: signed.exe
Debug info file: SigningPdb.pdb
Executable:
TimeDateStamp: bc78c18e
Debug info: 2 ( CodeView )
TimeStamp: a7b373e5 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 97 RVA: 000026a0 FileOffset: 000008a0
CodeView format: RSDS
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
PdbFile: ...ReleaseSigningPdb.pdb
Debug info: 16 ( Unknown )
TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 0 RVA: 00000000 FileOffset: 00000000
Debug information file:
Format: PDB 7.00
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
Result: Matched
The timestamp is in the COFF header. That header is only 24 bytes in size and will not change during code signing.
Most changes will happen in a new section for certificates. This section, however, will also be ignored during code signing. Otherwise, a second signature would destroy the first signature. (BTW: this section has been used to transport malicious code inside a signed executable)
Of course, the "usual" checksums, which do not consider the EXE/DLL file structure, will report a different checksum.
What may have happened to your DLL or EXE?
- you have accidentally rebuilt it, so the time stamp of your DLL does not match the PDB any more
- you are using aspect oriented programming (AOP) in .NET and there is some code weaving happening after a rebuild. These tools might not be able to rebuild the PDB after weaving, so the PDB mismatch is already there before the DLL is code signed.
answered Mar 23 at 18:15
Thomas WellerThomas Weller
29.7k1171143
add a comment |
Code signing an executable or DLL does not affect the debug header of the executable. Thus, it will still match the PDB.
...SigningPdbbinRelease>symchk signed.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
...SigningPdbbinRelease>symchk unsigned.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
And
...SigningPdbbinRelease>ChkMatch.exe -c signed.exe SigningPdb.pdb
ChkMatch - version 1.0
Copyright (C) 2004 Oleg Starodumov
http://www.debuginfo.com/
Executable: signed.exe
Debug info file: SigningPdb.pdb
Executable:
TimeDateStamp: bc78c18e
Debug info: 2 ( CodeView )
TimeStamp: a7b373e5 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 97 RVA: 000026a0 FileOffset: 000008a0
CodeView format: RSDS
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
PdbFile: ...ReleaseSigningPdb.pdb
Debug info: 16 ( Unknown )
TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 0 RVA: 00000000 FileOffset: 00000000
Debug information file:
Format: PDB 7.00
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
Result: Matched
The timestamp is in the COFF header. That header is only 24 bytes in size and will not change during code signing.
Most changes will happen in a new section for certificates. This section, however, will also be ignored during code signing. Otherwise, a second signature would destroy the first signature. (BTW: this section has been used to transport malicious code inside a signed executable)
Of course, the "usual" checksums, which do not consider the EXE/DLL file structure, will report a different checksum.
What may have happened to your DLL or EXE?
- you have accidentally rebuilt it, so the time stamp of your DLL does not match the PDB any more
- you are using aspect oriented programming (AOP) in .NET and there is some code weaving happening after a rebuild. These tools might not be able to rebuild the PDB after weaving, so the PDB mismatch is already there before the DLL is code signed.
answered Mar 23 at 18:15
Thomas WellerThomas Weller
29.7k1171143
Code signing an executable or DLL does not affect the debug header of the executable. Thus, it will still match the PDB.
...SigningPdbbinRelease>symchk signed.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
...SigningPdbbinRelease>symchk unsigned.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
And
...SigningPdbbinRelease>ChkMatch.exe -c signed.exe SigningPdb.pdb
ChkMatch - version 1.0
Copyright (C) 2004 Oleg Starodumov
http://www.debuginfo.com/
Executable: signed.exe
Debug info file: SigningPdb.pdb
Executable:
TimeDateStamp: bc78c18e
Debug info: 2 ( CodeView )
TimeStamp: a7b373e5 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 97 RVA: 000026a0 FileOffset: 000008a0
CodeView format: RSDS
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
PdbFile: ...ReleaseSigningPdb.pdb
Debug info: 16 ( Unknown )
TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 0 RVA: 00000000 FileOffset: 00000000
Debug information file:
Format: PDB 7.00
Signature: b8ed520c-cdfc-486b-8e1a-7c0752a2a41f Age: 1
Result: Matched
The timestamp is in the COFF header. That header is only 24 bytes in size and will not change during code signing.
Most changes will happen in a new section for certificates. This section, however, will also be ignored during code signing. Otherwise, a second signature would destroy the first signature. (BTW: this section has been used to transport malicious code inside a signed executable)
Of course, the "usual" checksums, which do not consider the EXE/DLL file structure, will report a different checksum.
What may have happened to your DLL or EXE?
- you have accidentally rebuilt it, so the time stamp of your DLL does not match the PDB any more
- you are using aspect oriented programming (AOP) in .NET and there is some code weaving happening after a rebuild. These tools might not be able to rebuild the PDB after weaving, so the PDB mismatch is already there before the DLL is code signed.
answered Mar 23 at 18:15
Thomas WellerThomas Weller
29.7k1171143
answered Mar 23 at 18:15
Thomas WellerThomas Weller
29.7k1171143
answered Mar 23 at 18:15
Thomas WellerThomas Weller
29.7k1171143
answered Mar 23 at 18:15
Thomas WellerThomas Weller
29.7k1171143
29.7k1171143
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55309226%2fdoes-signing-a-dll-invalidate-a-pdb-file%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
With Signing you mean Authenticode signing? I am not aware that this changes the debug header. It more looks like you did recompile the dll from the same sources. You can force a load with .reload -f -i libcef.dll if you symbol path contains the directory where your new pdb is located. Use .sympath+ F:srcout to add it. Then debugging should be a non issue.
– Alois Kraus
Mar 23 at 0:10
@AloisKraus Yes, authenticode signing. Force reload seems to work fine. I'm more concern if I may be debugging wrong stuff because of symbol mismatch. Do you how can I look at the debug header?
– kiewic
Mar 23 at 0:36
I notice your pdb has a .dll appended to it afaik vc creates pdb with the .dll stripped ie it creates a libcef.pdb instead of libcef.dll.pdb do you have a -Fxyz switch passed on that provides a different name for pdb in your projects ? no signing afaik doesn't change anything inside your binary (imagine ms embedding an oops backdoor if it does that cant it ? ) use dumpbin /headers to check the path embedded inside binary
– blabb
Mar 23 at 8:18