I wrote some kind of WinDBG extension (strictly for internal test purposes) and tried to load it into WinDBG (version 6.10.0003.233) running on Windows Vista SP1 x86. But that’s what I was shown:
The call to LoadLibrary(denext.dll) failed, Win32 error 0n577
“Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.”
Please check your debugger configuration and/or network access.
Then I tried to sing this extension with TestCertforWDK but the problem still remains the same. Should I use a “normal”, full-blown certificate (say, which is used for signing production drivers) or should I play with some subtle WinDBG settings to allow unsigned extensions to be loaded? Or should I completely turn off digital signature verification in the system?
Thanks beforehand. Any suggestions will be highly appreciated.
I wrote some kind of WinDBG extension (strictly for internal test purposes) and tried to load it into WinDBG (version 6.10.0003.233) running on Windows Vista SP1 x86. But that’s what I was shown:
The call to LoadLibrary(denext.dll) failed, Win32 error 0n577
“Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.”
Please check your debugger configuration and/or network access.
Then I tried to sing this extension with TestCertforWDK but the problem still remains the same. Should I use a “normal”, full-blown certificate (say, which is used for signing production drivers) or should I play with some subtle WinDBG settings to allow unsigned extensions to be loaded? Or should I completely turn off digital signature verification in the system?
Thanks beforehand. Any suggestions will be highly appreciated.
But the thing is that I previously used this extension in WinDBG running on Windows XP, and it was perfectly working back then. But recently I had slightly modified this extension (added some additional dprintf() calls to detail output) and it has got broken on Windows Vista. :-((( Additionally the original (but recompiled) extension doesn’t work either.
But the thing is that I previously used this extension in WinDBG running on Windows XP, and it was perfectly working back then. But recently I had slightly modified this extension (added some additional dprintf() calls to detail output) and it has got broken on Windows Vista. :-((( Additionally the original (but recompiled) extension doesn’t work either.
There is no extra check whether windbg extension is signed; rather, this is just ERROR_INVALID_IMAGE_HASH error returned from LoadLibrary() call.
The call to LoadLibrary(denext.dll) failed, Win32 error 0n577
“Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.”
If possible, please redirect your request to xxxxx@microsoft.com and attach the extension, we could help examine what the problem is.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Friday, November 14, 2008 1:40 PM
To: Kernel Debugging Interest List
Subject: RE: RE:[windbg] WinDBG extension signing
I think the real question is why MS would force us to sign windbg extensions? Sounds insanely dopey to me.
But the thing is that I previously used this extension in WinDBG running on Windows XP, and it was perfectly working back then. But recently I had slightly modified this extension (added some additional dprintf() calls to detail output) and it has got broken on Windows Vista. :-((( Additionally the original (but recompiled) extension doesn’t work either.
I recently ran into a load issue with a debug extension that I built with
the Vista WDK (using the Vista build environment) that wouldn’t load on a
debugger running under WXP. I rebuilt it using the WXP build environment
and it started working. You might try rebuilding yours under the Vista
environment and see what happens. I haven’t had to sign my extensions.
-Barrett
On Fri, Nov 14, 2008 at 1:40 PM, Jeff Curless wrote:
> I think the real question is why MS would force us to sign windbg > extensions? Sounds insanely dopey to me. > > -Jeff > > -----Original Message----- > From: xxxxx@lists.osr.com [mailto: > xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com > Sent: Friday, November 14, 2008 10:13 AM > To: Kernel Debugging Interest List > Subject: RE:[windbg] WinDBG extension signing > > Thanks for the quick reply, > > But the thing is that I previously used this extension in WinDBG running on > Windows XP, and it was perfectly working back then. But recently I had > slightly modified this extension (added some additional dprintf() calls to > detail output) and it has got broken on Windows Vista. :-((( Additionally > the original (but recompiled) extension doesn’t work either. > > WBR, > Konstantin Manurin > > — > You are currently subscribed to windbg as: xxxxx@verdasys.com > To unsubscribe send a blank email to xxxxx@lists.osr.com > > — > You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ > To unsubscribe send a blank email to xxxxx@lists.osr.com >
I recently ran into a load issue with a debug extension that I built
with the Vista WDK (using the Vista build environment) that wouldn’t
load on a debugger running under WXP. I rebuilt it using the WXP
build environment and it started working. You might try rebuilding
yours under the Vista environment and see what happens. I haven’t had
to sign my extensions.
This reminds me of an interesting bug we ran into for a client a number
of years ago. Most of the developers ran Windows 2000 machines, while
the main build server still ran Windows 98 SE. We would find that our
own drivers worked just fine, but some of the time, the nightly build
drivers would fail to load on NT, although they worked fine on 98.
After some investigation, this turned out to be a very fundamental
problem: the checksum was wrong. The linker in the DDK takes a checksum
of the finished executable and embeds it in the binary. 98 didn’t care,
but NT checks the checksum for drivers, and bluescreens if it doesn’t match.
So, how did the checksum get wrong? The checksum algorithm maps the
file into memory, then sums the image 16 bits at a time. If the file
contains an odd number of bytes, the checksum algorithm picks up one
extra byte beyond the end of the file. A file mapping always runs to
the end of the page, so the extra byte is always available. It turns
out that NT zeros out the extra bytes in a file mapping beyond end of
file, but 98 does not. So, the checksummer would pick up one random
byte, and screw up the checksum.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Today I checked file and found this: LINKER_FLAGS=/NOLOGO /integritycheck /map The second option was mistakenly taken from a driver file (copy-paste case) and deleting it solved this problem.
Thanks again for the support, sorry for bothering you with this artificial problem.
Not at all; this is good to know, especially as (as best as I can tell) ‘-integritycheck’ is neither
documented nor even part of the output of ‘link /?.’
Today I checked file and found this: > LINKER_FLAGS=/NOLOGO /integritycheck /map > The second option was mistakenly taken from a driver file (copy-paste case) and deleting it solved this problem. > > Thanks again for the support, sorry for bothering you with this artificial problem. > > WBR, > Konstantin Manurin >
Pretty sure that’s for in-paging signature checks.
S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Monday, November 17, 2008 6:58 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] WinDBG extension signing
Not at all; this is good to know, especially as (as best as I can tell) ‘-integritycheck’ is neither
documented nor even part of the output of ‘link /?.’
Today I checked file and found this: > LINKER_FLAGS=/NOLOGO /integritycheck /map > The second option was mistakenly taken from a driver file (copy-paste case) and deleting it solved this problem. > > Thanks again for the support, sorry for bothering you with this artificial problem. > > WBR, > Konstantin Manurin >
i cant find where i read it but iirc /integritycheck just ors 0x0800 to
peheader->Optionalheader->DllCharecteristics ( i think i was having a look
at some peheader value that had some odd unusual number )
and possibly hexeditable too for binaries that arent produced by the latest
and greatest of visual studio linkers
regards
raj
On 11/17/08, Martin O’Brien wrote: > > Not at all; this is good to know, especially as (as best as I can tell) > ‘-integritycheck’ is neither documented nor even part of the output of ‘link > /?.’ > > > Thanks, > > mm > > xxxxx@gmail.com wrote: > >> Thank you guys for the detailed replies. >> >> Today I checked file and found this: >> LINKER_FLAGS=/NOLOGO /integritycheck /map >> The second option was mistakenly taken from a driver file >> (copy-paste case) and deleting it solved this problem. >> >> Thanks again for the support, sorry for bothering you with this artificial >> problem. >> >> WBR, >> Konstantin Manurin >> > > — > You are currently subscribed to windbg as: xxxxx@gmail.com > To unsubscribe send a blank email to xxxxx@lists.osr.com >
On 11/18/08, raj_r wrote: > > > i cant find where i read it but iirc /integritycheck just ors 0x0800 to > peheader->Optionalheader->DllCharecteristics ( i think i was having a look > at some peheader value that had some odd unusual number ) > and possibly hexeditable too for binaries that arent produced by the latest > and greatest of visual studio linkers > > regards > > raj > > > > On 11/17/08, Martin O’Brien wrote: >> >> Not at all; this is good to know, especially as (as best as I can tell) >> ‘-integritycheck’ is neither documented nor even part of the output of ‘link >> /?.’ >> >> >> Thanks, >> >> mm >> >> xxxxx@gmail.com wrote: >> >>> Thank you guys for the detailed replies. >>> >>> Today I checked file and found this: >>> LINKER_FLAGS=/NOLOGO /integritycheck /map >>> The second option was mistakenly taken from a driver file >>> (copy-paste case) and deleting it solved this problem. >>> >>> Thanks again for the support, sorry for bothering you with this >>> artificial problem. >>> >>> WBR, >>> Konstantin Manurin >>> >> >> — >> You are currently subscribed to windbg as: xxxxx@gmail.com >> To unsubscribe send a blank email to xxxxx@lists.osr.com >> > >