I am currently trying to build an application, that will talk to the super IO chip using port IO. As part of that, I am trying to develop a kernel-mode windows driver that I can contact, and which will do the IO for me. I have therefore downloaded the Windows Driver Kit v7.1.0, build 7600.16385.1, and I am trying to compile and install the sample portio driver, which is provided by WDK, since it seems to be quite close to what I need.
I have compiled the driver in both free and checked x86 XP build environments. This works fine, but when I try to install the resulting driver, using the provided instructions - which basically just amount to using the Add Hardware Wizard, and then supplying the files manually - I get the following error:
-The following hardware was installed: Sample PortIO Driver (KMDF)
-The software for this device is now installed, but may not work correctly
-Windows cannot load the driver for this hardware. The driver may be corrupted or missing. (Code 39)
So, I see two explanations: corrupted or missing. Missing, as far as I can tell, given my environment variables and .inf file, would mean that the generated .sys file is not in c:\windows\system32\drivers, but when I look there, the file is there.
So that would mean that the file is corrupted. Given that I haven't touched the driver code, and that I have found others with the same problem, it doesn't seem to be a problem with my compilation, but rather with the code itself, or some common combination of machine type and code. But I may be wrong.
Does anybody have any suggestions on how to solve this?
I would recommend enabling SetupAPI logging as described in the following document from Microsoft:
http://www.microsoft.com/whdc/archive/setupapilog.mspx
For Windows 7, the log files are split up as described here:
http://support.microsoft.com/kb/927521
You may be able to isolate the problem with the additional information in the SetupAPI logs.
Related
I have a custom windows kernel driver I have compiled. I sign it with a test cert, create the cat file from the cdf, stamp the inx into a inf file, then load it with pnputil. I then create a software device with SwDeviceCreate so the OS will pair my driver and the driver. This works fine.
The problem is if i screw up something in the compilation and get something like an error code 39 (viewable in device manager), I do not see that error. Instead the OS seems to try to fix the error by loading the previously working version of the driver. In order to see that error, I have to purge the driver and device using pnputil /d oem42.inf along with a pnputil /remove-device, then restart my PC, that seems to fix the issue. This is difficult because it means i have to restart my PC every time i run a test. I know crashing a kernel driver can cause a panic anyway and cause me to restart, but there seems to be instances where this is not the case and the OS tries to rectify the issue without me (as it probably should).
So my question is this. Is there a way to completely purge my driver without a complete restart in-between installations/tests so I can correctly break it. I know I am suppose to use another machine and remote debug kernel drivers, but i do not have access to another machine right now that can support windows 11.
I am trying to debug a driver in UEFI firmware (OVMF) via gdb as described here:
https://github.com/tianocore/tianocore.github.io/wiki/How-to-debug-OVMF-with-QEMU-using-GDB
It works well, but I discovered that just having debug symbols for my driver is not enough. I also need debug symbols for the whole OVMF image to properly see what's going on. I have a lot of .debug files after OVMF is built with edk2, but I don't understand which ones I need to load into gdb, and what addresses I should use.
I found some instructions involving DebugPkg, but I couldn't make gdb_uefi.py work no matter what. It always failed to locate EFI_SYSTEM_TABLE_POINTER.
In the end, I ended up writing my own script, which implements gdb command that does manage to successfully load all debug symbols. It is probably a worse solution, since it requires a setup: "debug.log" with driver addresses must be present when loading is performed, so you need to run QEMU at least once first. But, this is good enough for me.
My script can be found here:
https://github.com/artem-nefedov/uefi-gdb
I am trying to install just checked HAL and kernel on Windows 7 SP 1 32-bit. The instruction on the Microsoft Dev Center web site MSDN suggests I do the following:
Open the file %SystemRoot%\Inf\setupapi.dev.log and search for hal.dll.
You should find a line like TargetFilename - 'hal.dll'
In the same section of the log file, look for the corresponding SourceFilename. The name to the right of SourceFilename is the name of the HAL file that you need to copy from the checked build.
setupapi.dev.log file on my machine, however, does not mention hal.dll. In fact, I searched for hal.dll in the inf directory and found no mention of it in any other log file.
I did find mentions of acpi_hal and ACPIAPIC_HAL in setupapi.dev.log, but I'm not sure if this can help me select the correct hal.
Is there any other way to determine which hal to use?
EDIT: I figured it out. See below.
I figured it out. In Windows Internals, 6th Edition, on page 60, there's a list of x86 HALs:
Halacpi.dll - Advanced Configuration and Power Interface (ACPI) uniprocessor-only machines.
Halmacpi.dll - Advanced Programmable Interrupt Controller (APIC) with ACPI.
Since my computer is multiprocessor and because ACPIAPIC_HAL was listed in the log file, I tried halmacpi.dll and it worked.
Thanks.
A while back I was following some tutorials an assembly. I was running it all on a windows machine, compiling with NASM and then writing the compiled code to a floppy disk, then reboot and try the code. This process was long and time consuming and sadly was not on a mac. When I found out that Xcode for mac installed NASM I immediately tried to compile some code. The code compiled fine. The issue is testing it. On a mac I have no floppy (not like I want to use one) so Im not sure how to test this. I looked in to Q (kju) and found it would only emulate things on an ISO file. So I guess what Im asking is is it possible to install the compiled code on an ISO file for testing? (Note: the code when compiled forms a .bin file)
Thanks for any help
I don't know exactly what you are trying to test (a boot loader maybe?) but you don't need to reboot or boot from a disk just to run assembled code (unless it is a boot loader or something).
Either way, if you need to "reboot" to test, I suggest running an emulator. Sun VirtualBox is super easy to use and free and emulates a standard x86 architecture (including floppy drives)! So that may work for you in the short term. If you ever want to create an ISO image in the future, you can do that with the command line utility hdiutil. In a terminal window, type man hdiutil or visit the online man page for more information on using that to create all kinds of disk images.
I really hope someone can be of help to me because this problem has me totally stuck and frustrated.
Yesterday I installed a fresh and shiney new Windows 7 x64 onto a development box.
I got VS2008 installed, Tortoise SVN, did a checkout, compiled my currently project, all fine and dandy.
But when I go to run (either F5 in VS or just running the exe from the shell) I get a dialog box that looks like this:
(source: aliparr.net)
So I fiddle around and can't see an obvious problem. I bust out depends.exe, thinking maybe there's a dll missing, and I get this:
(source: aliparr.net)
So I play, finding different versions of gpsvc.dll and ishims.dll and putting them in with the .exe, No luck.
If I do a profile in depends (which follows the Output window of vs), I get this:
..
Loaded "c:\windows\syswow64\ADVAPI32.DLL" at address 0x75F20000 by thread 1. Successfully hooked module.
Loaded "c:\windows\syswow64\LPK.DLL" at address 0x76B20000 by thread 1. Successfully hooked module.
Loaded "c:\windows\syswow64\USP10.DLL" at address 0x761C0000 by thread 1. Successfully hooked module.
Loaded "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\MSVCR90.DLL" at address 0x70570000 by thread 1. Successfully hooked module.
Loaded "c:\users\ali\desktop\repository\development\trunk\spree\bin\debug\OPENLDAP.DLL" at address 0x001E0000 by thread 1. Successfully hooked module.
Exited "c:\users\ali\desktop\repository\development\trunk\spree\bin\debug\SPREE.EXE" (process 0x5D4) with code -1073741701 (0xC000007B) by thread 1.
So it seems openldap.dll is the last thing to get loaded before it all goes wrong. I require this dll because I use cURL within the application to do a little JSON communicating...
I've tried playing with moving files and trying differing dlls, but honestly I'm acting a little blind here. Can someone please help or point me in the right direction?
It should be noted these dlls and setup work fine in Windows Vista x64 and x86 - is this a Windows 7 thing?
Massive thanks in advance, I might still have some hair left after this is done.
Edit
I've now realised curl.exe dies in exactly the same way with openldap.dll - I guess some windows 7 issue?
Can you/does anyone have a curl without the dependency on openldap? Is there another lightweight C/C++ library out there that'll let me fetch a document over http and do the odd http POST ?
Thanks
I had a very similar problem myself: I was developing a C program (using the MinGW gcc compiler) which used the curl library to do http GET operations. I tested it on Windows XP (32-bit) and Windows 7 (64-bit). My program was working in Windows XP, but in Windows 7 it crashed with the same 0xc000007b error message as the OP got.
I used Dependency Walker on a down-stripped program (with only one call to the curl library:curl_easy_init()). I essentially got the same log as yours, with OPENLDAP.DLL as the last successfully loaded module before the crash.
However, it seems my program crashed upon loading LIBSASL.DLL (which was the next module loaded according to the log from Dependency Walker run on Windows XP).
When looking again in the log from Dependency Walker on Windows 7, LIBSASL.DLL indeed shows up a x64 module. I managed to get my program to run by copying a 32-bit version of the DLL file from another application on my harddisk to my program's directory.
Hopefully this will work for other people having similar problems (also for the OP if the problem still wasn't resolved after these years). If copying a 32-bit version of LIBSADL.DLL to your program's directory doesn't help, another module might cause the crash. Run Dependency Walker on both the 32- and 64-bit systems and look up the module name from the log of the successful run.
I cannot answer your questions completely, I've compiled libcurl on Windows 7 Professional x64 and I don't have any issues. Although I haven't compiled it with OpenLDAP support so I suppose that's where the issue lies.
Regarding the IEShims.dll, Dependency Walker usually reports this as a missing module. Can't remember the exact reason but it was something about loading it dynamically when it's not found in %Path%.
If you however need to debug this and are on Windows 7 then try doing a hard link from %ProgramFiles%\Internet Explorer\IEShims.dll to %windir%.
Although, I see on the screen dump that it sure looks like Spree.exe isn't loaded as a x64 binary, which could very well be it. There's a difference in loading exported functions and piping or exec() a binary, the first mentioned requires that the architecture is the same for both the importer and exporter.
I've also found that mine is trying to load a 64 bit version of LIBSASL.DLL - the one that came with my 64 bit Tortoise distribution. I also only need curl for pulling a bit of JSON data. I think the best solution is going to be to rebuild libcurl from source and exclude the LDAP since I don't need it anyway.
Similar issue here. DLL dependents GPSVC.DLL and MSVCR90.DLL.
I managed to get rid of IESHIMS.dll by setting my environment variables path to C:\Program Files (x86)\Internet Explorer. Surely that shouldn't need to be done!
Is there a fix to this yet?
libsasl requires ieshims.dll, if you don't have sasl support in openldap, then ieshims.dll won't be required.
If you use windows x64 you have to copy your dll to c:/windows/SysWoW64. I have had the same problem when i wanted use pthreads in windows os 8. When I was copied pthreads dll to SysWow64 the program was run sucessfully.