Hi,
Can anyone give me, or point me to a wndbg debugger extension that compiles and loads when built with the latest longhorn DDK? I can’t figure out what the magic combination of header files is that allows it to compile. Specifically, it wants “RaiseException”, but if I include winbase.h, all hell breaks loose. If I hack the definition into my own header file it loads, but then complains that “The specified procedure could not be found”.
You’ve got a couple of issue here.
As far as building, any of the samples distributed with the latest WinDbg should build fine. I just tried building “exts” (sdk\samples\exts), and built it under Longorn AMD64 CHK, and it built fine. Generally, you have to set at least DBGSDK_INC_PATH, DBGSDK_LIB_PATH and sometimes SDK_LIB_PATH in SOURCES yourself, but otherwise, they all should build fine.
What wants “RaiseException?” Including WinBase.h in any project that also uses Windows.H is going to cause problems. I have no idea of why you’re getting the error about RaiseException, as you didn’t post any source code. Make sure that you are including Windows.H first, and then not including WinBase.H.
“The specified…” Welcome to the joys of debugging windbg extensions. Although there is no easy way to tell this from that error message, it almost always means that some dependency required by the extension can not be found, assuming that you are specifying a valid full path to the extension itself with .load, or have set a valid search path with .extpath. As the missing dll can be one that is not directly imported by your extension, the easiest way to figure this out is to download Depends.EXE
http://www.dependencywalker.com/
and see what it says is missing. If you get weird messages about a delayed import involving something to do with either Java or the Vista Desktop Manager being missing, you can ignore them. What you are probably missing is MSVCRT8, which really, really sucks to address. The basic idea is to make sure that everything required by your extension is available in your system PATH.
Are you using one of the samples? If not, and this is your first extension, you want want to do so. In particular, the new EngExtCpp is nicer, in my opinion, as long as you either rebuild the sources (included) to not use MSVCRT8, or are willing to deal with the install nonsense that generally ensues with its use.
Good luck,
mm
Hi mm,
Thanks for the response. I’ve worked around the compilation issues, but I’m still stuck on the dependency issue. In fact, I did as you suggested and compiled and ran the sample extension provided by Microsoft and hit the same problem. I ran depends against the both my extension and the sample extension and both complain about MSVCRT (not MSVCRT8…??). The strange thing is, from what I can see, it can find MSVCRT.DLL (which is under WINDOWS\system32), but it appears to be complaining that it doesn’t contain “_except_handler4_common”. I’m having trouble understanding exactly what depends is trying to tell me. This does have me wondering, though… I’m running the debugger on an XP system, but I’m compiling the extension using the longhorn DDK build environment (so I pick up the proper header files required by my extension). Perhaps the extension is looking for a routine that is unique to longhorn/vista.
Why are you compiling for Longhorn? WinDbg Extensions are somewhat strange in that they usually compile for 2K3 no matter on what platform they are to run, so it may not cause problems. In either case, it is not the cause of your “_except_handler4_common” problem. That is, indeed, a MSVCRT8 export. MSVCRT8 is the file name; it’s resource name is still MSVCRT, so what’s happening is that Depends is finding MSVCRT.DLL, and it does not contain the export, because only MSVCRT8 has it.
This problem really deeply sucks to fix, because, unlike previous versions, MSVCRT8 uses assemblies, so just pointing your path to it does not (in my experience) fix the problem, as the assemblies force it to do otherwise. Unfortunately, I don’t have much to tell you here that will help, as this is not a problem for which I had patience when I ran it to it the first time. Here are my basic ideas, such as they are, in no particular order:
Try copying MSVCRT8.DLL to the same folder as your extension and see what happens. I don’t believe that this will fix it, although there is a lot out there that says that this will word. This has not been my experience, but it’s worth a shot.
Someone on this list told me that the solution to this problem (1) is to create something called a “Setup Project” in VS. I don’t recall who told me this, but it was someone who definitely knows what they’re doing; I just didn’t have the patience for this.
If you’re trying to use the extension on a machine on which you do not have VS 2005 installed, and you have an available license, install it on that machine. Not a pretty solution, but it does fix it.
If the sample you chose is the one based on EngExtCpp, rebuild the sources for it (provided with the WinDbg SDK) to not use MSVCRT8. This is what I usually do, but it won’t help you if you’re not using this specific sample.
Get out the WDK documentation and see if there is a macro that determines what/where CRT you link against. You need to make sure that you are not using the import library for MSVCRT8, but rather one of the olders ones. Option B is basically the same, but make BUILD use the static multithreaded version (-MT). I do not personally use BUILD, so I can’t help you here.
If you’re familiar with Makefiles, it’s quite easy and quick to write one that will compile a WinDbg Extension without using MSVCRT8; just use the -MT CL option, -NODEFAULTLIB with the linker, and specify library paths. This is what I do, if I’m not using EngExtCpp (actually, I still use a custom Makefile there as well).
Although not exactly PC, I would recommend 6, assuming that you are familiar with Makefiles, and that you don’t get better advice. It’s easy, it works, and you can beat your head against the wall for a long time trying to get MSVCRT8 to cooperate, unless someone else here can tell you specifically what to do.
Good luck,
mm
I never tried to build WinDbg extension but encountered problems with MSVCRT8 in different projects. So few comments:
ad 1. it usually works but it is necessary to copy also the manifest. Basically, everything from directory (hey, I almost used the buzzword “folder”!) with MSVCRT redistributables from VS 2005.
ad 3. yes, it works. It is also possible to create a simple installation with MSVCRT redistributables only but don’t ask me how to do it.
ad 5. static library is the way to go if possible. It eliminates all the neverending problems. We use switched to it for our internal tools. Executables are huge but any QA person can use them with no problem. For released software we of course create installations with all necessary redistributables.
Both #1 and #3 solve problem at one OS installation only and it is necessary to repeat the procedure at any new OS/machine. It really sucks. That’s why we switched to static library.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@evitechnology.com[SMTP:xxxxx@evitechnology.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 20, 2007 12:51 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] building debugger extension dll with longhornWhy are you compiling for Longhorn? WinDbg Extensions are somewhat strange in that they usually compile for 2K3 no matter on what platform they are to run, so it may not cause problems. In either case, it is not the cause of your “_except_handler4_common” problem. That is, indeed, a MSVCRT8 export. MSVCRT8 is the file name; it’s resource name is still MSVCRT, so what’s happening is that Depends is finding MSVCRT.DLL, and it does not contain the export, because only MSVCRT8 has it.
This problem really deeply sucks to fix, because, unlike previous versions, MSVCRT8 uses assemblies, so just pointing your path to it does not (in my experience) fix the problem, as the assemblies force it to do otherwise. Unfortunately, I don’t have much to tell you here that will help, as this is not a problem for which I had patience when I ran it to it the first time. Here are my basic ideas, such as they are, in no particular order:
Try copying MSVCRT8.DLL to the same folder as your extension and see what happens. I don’t believe that this will fix it, although there is a lot out there that says that this will word. This has not been my experience, but it’s worth a shot.
Someone on this list told me that the solution to this problem (1) is to create something called a “Setup Project” in VS. I don’t recall who told me this, but it was someone who definitely knows what they’re doing; I just didn’t have the patience for this.
If you’re trying to use the extension on a machine on which you do not have VS 2005 installed, and you have an available license, install it on that machine. Not a pretty solution, but it does fix it.
If the sample you chose is the one based on EngExtCpp, rebuild the sources for it (provided with the WinDbg SDK) to not use MSVCRT8. This is what I usually do, but it won’t help you if you’re not using this specific sample.
Get out the WDK documentation and see if there is a macro that determines what/where CRT you link against. You need to make sure that you are not using the import library for MSVCRT8, but rather one of the olders ones. Option B is basically the same, but make BUILD use the static multithreaded version (-MT). I do not personally use BUILD, so I can’t help you here.
If you’re familiar with Makefiles, it’s quite easy and quick to write one that will compile a WinDbg Extension without using MSVCRT8; just use the -MT CL option, -NODEFAULTLIB with the linker, and specify library paths. This is what I do, if I’m not using EngExtCpp (actually, I still use a custom Makefile there as well).>
Although not exactly PC, I would recommend 6, assuming that you are familiar with Makefiles, and that you don’t get better advice. It’s easy, it works, and you can beat your head against the wall for a long time trying to get MSVCRT8 to cooperate, unless someone else here can tell you specifically what to do.
Good luck,
mm
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Problem solved. Apparently the missing symbol is only available on Vista/Longhorn. In order to run the extension DLL that is compiled with the longhorn DDK on my XP system, I need to have the following line in my Sources file: _NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
Many thanks for your responses, and thanks to Mario at Microsoft who answered the question on the microsoft.public.windbg list.