locked
Can't get rebuilt WinXP driver to function. RRS feed

  • Question

  • I am trying to resurrect a device driver build so I can debug a problem that has cropped up after a decade of successful use.   I can't get the unmodified code to function in the system. The driver was developed in 2001 by someone else.  I have successfully recompiled the source code project to a .sys file.  Not having made any changes to the source, I expected to be able to drop the .sys file in the \drivers folder, reboot an be able to see it work - it doesn't.  I then tried to use Device Manager with the INF to update the driver, which appears to be successful.  The app still can't open the device though.  The application always fails when it tries to open the driver, with Windows System Error Code 2 (ERROR_FILE_NOT_FOUND).  This is the application code that fails:

    wsprintf(ach, _T("\\\\.\\PCIDSP%d"), board);
    
    hBoard[board] = CreateFile(ach, GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL);
    
    

    So, what am I missing?  It's probably something obvious to a driver developer - which I'm not.  I wonder if I might not have the same DDK as the original build since I had to setup a new build environment.  I'm using win2kddk.exe.  You would think that would be more a compile/link issue rather than a runtime failure.  Both the checked and free builds are slightly different sizes than the original .sys file.

    One detail I don't understand is the driver name is "PCIDSP" but the device opens "PCIDSP0".  Where can I observe Windows exposing the enumerated device name?  The querydriver app for example only shows the base module name without the enumeration.

    Maybe I'm not doing something necessary to put the recompiled & different size .sys file in place?

    Some background: the original driver was developed in 2001 on Windows 2000 under VS6.  I've successfully deployed the original device driver install on hundreds of Windows 2000 and Windows XP systems.  Now, I'm building under VS6SP6 on Windows XP 32-bit, SP3 and deploying onto the same.

    This is just a prerequisite to looking at the real problem! Any suggestions on how to get my 2011 build of a 2001 driver to work again would be greatly appreciated.

    • Edited by elindaman Thursday, February 17, 2011 3:52 PM Improve readability
    Thursday, February 17, 2011 3:47 PM

Answers

  • To state the obvious: you are asking questions about the implementation of some custom c++ wrapper library's implementation of various WDK interfaces. Nobody is going to to know what this stuff does or why it is broken. You should use a debugger to find out where the symbolic link creation is failing and why.
    Mark Roddy Windows Driver and OS consultant www.hollistech.com
    Thursday, February 17, 2011 10:10 PM

All replies

  • Is the device manager showing the device is operating ok?  If so, you may want to use WinObj http://technet.microsoft.com/en-us/sysinternals/bb896657 to see if the device and its symbolic link are present in the object store.

    You may want to go to a newer DDK/WDK, while this may hit some compile issues, you will not have to worry about compiler versus DDK issues.


    Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr
    Thursday, February 17, 2011 4:02 PM
  • Thanks Donald for the reply.  The device is working OK according to Device Manager.  WinObj shows a device called "PCIDSPDRV".  There are no symbolic links for this device.  This is getting me closer to the cause of the problem because when I reinstall the original driver using the installation EXE, there IS another device in the list called "PCIDSP0".  That's the name the application is trying to CreateFile() on and failing with the new driver build installed.

    I installed the latest WDK 7.1.0, but it looks like I'll need to change the makefile to get it to build.

    The device driver code is calling CreatSymbolicLink() in its Init() section.  I guess I need to focus on why the symbolic link isn't getting created by the driver code (see below).  There doesn't seem to be any code that creates a symbolic link with the added enumeration, i.e. "PCIDSP0".  Any insight on this is appreciated.

    inline NTSTATUS CPciDspDeviceExtension::Init(PDEVICE_OBJECT pDO, CPciDriver &driver)
    {
    	NTSTATUS Status = CPciDeviceExtension<CCommonDeviceExtension>::Init(pDO, driver);
    	if (!NT_SUCCESS(Status)) {
    		return Status;
    	}
    
     // These are used for IRP_MJ_READ and IRP_MJ_WRITE
     GetDeviceObject()->Flags |= DO_BUFFERED_IO;
     // AlignmentRequirement = FILE_BYTE_ALIGNMENT;
    
    	Status = CreateSymbolicLink(driver.usDevName, driver.usDevName);
    	if (!NT_SUCCESS(Status)) {
    		return Status;
    	}
    
    	GetDeviceObject()->Flags &= ~DO_DEVICE_INITIALIZING;
    
    	// Everything went OK and we're ready to go
    	return STATUS_SUCCESS;
    }
    
    NTSTATUS CDrvDeviceExtension::Init(PDEVICE_OBJECT pDO, CDriver& driver)
    {
    	NTSTATUS	Status = CCommonDeviceExtension::Init(pDO, driver);
    	if (NT_SUCCESS(Status)) {
    		CTempUnicodeString usPciDspDrv(L"PCIDSPDRV");
    		Status = CreateSymbolicLink(usPciDspDrv, usPciDspDrv);
    	}
    	return Status;
    }
    

    Edward R. Lindaman
    • Edited by elindaman Thursday, February 17, 2011 9:50 PM typo
    Thursday, February 17, 2011 9:48 PM
  • First what framework are you using, since you have a wrapper around everything?  If you do not have a symbolic link you will not be able to open from user space.  I have to suspect CreateSymbolicLink at this point since I don't know what it is really doing.

     


    Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr
    Thursday, February 17, 2011 10:02 PM
  • To state the obvious: you are asking questions about the implementation of some custom c++ wrapper library's implementation of various WDK interfaces. Nobody is going to to know what this stuff does or why it is broken. You should use a debugger to find out where the symbolic link creation is failing and why.
    Mark Roddy Windows Driver and OS consultant www.hollistech.com
    Thursday, February 17, 2011 10:10 PM
  • Well, that explains a lot. It appears your using C++ and class definitions in the kernel. Acceptable kernel development is done in C and NOT C++, so it looks like someone made a really bad design decision way back in 2001. If it is DriverStudio, that framework has not been acceptable nor supported since around 2007, and it never handled power management properly.

    My recommendation would be re-write it for KMDF, since given the framework used for development, may never allow the driver to run on anything beyond XP. But ... that's personal opinion.


    Gary G. Little NanoTelesis Systems, LLC
    Saturday, February 19, 2011 10:39 PM