Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Legacy device can't find enough free resources

9track9track Member Posts: 2

I'm attempting to develop a KMDF driver for a legacy (non-PNP) ISA device. My test set up is Windows 10 21H2 running on VirtualBox with a custom plugin that simulates the I/O, IRQ and memory of the target hardware.

Despite this being a non-PNP device I believe I should be developing a PNP driver and using the INF file to specify the actual resources to be used. These will then be passed to the driver through the EvtDevicePrepareHardware callback.

I'm using the FactDef section rather than LogConfig because from what I've read the LogConfig section is both deprecated and ignored whereas FactDef is only deprecated. The INF section looks like this:

[MyISADrv_Device.NT.FactDef]
ConfigPriority=HARDRECONFIG
IOConfig=1C00-1C03(0FFF::)
IRQConfig=5
;MemConfig=D0000-DFFFF

The driver is installed by using the "Add legacy hardware" option in device manager. I see a call to EvtDriverDeviceAdd followed by a call to EvtDevicePrepareHardware with the specifed resources and everything works as expected.

If I uncomment the MemConfig line then I see the call to EvtDriverDeviceAdd but EvtDevicePrepareHardware is never called and the device is flagged as having a problem:

"This device cannot find enough free resources that it can use. (Code 12)"

After reading this article on hardware resources I added additional callbacks for EvtDeviceFilterRemoveResourceRequirements, EvtDeviceFilterAddResourceRequirements and EvtDeviceRemoveAddedResources. I see calls to the first two functions with the expected resources however the third function is never called.

The article above talks about the resource requests being passed to the bus driver, but I don't know what bus driver that would be as this is effectively a root-enumerated device.

As far as I can tell there doesn't appear to be a conflict with any other hardware for the address range D0000-DFFFF so does that mean that Windows thinks that those addresses simply don't exist and therefore cannot be used?

It may be that this works just fine on the target hardware but that isn't available for testing just yet so I'd like to understand why it fails in the virtual environment.

Comments

  • 9track9track Member Posts: 2

    So after a LOT of research and experimentation it seems that the answer is ACPI.

    I had assumed that because this is a legacy device Windows would just use the resources specified in the INF file without question because it has no way to detect if the device is actually there.

    It seems that's not the case because even though it's a legacy device it's still considered a resource consumer in ACPI terms so there has to be an equivalent resource producer to provide the address space that it sits within.

    Looking at the source for the DSDT provided with VirtualBox (vbox.dsl) under _SB.PCI0 there is a region that covers the addresses A0000-BFFFF for the VGA memory but nothing for the region D0000-DFFFF that I'm trying to use:

    DwordMemory( // descriptor for video RAM behind ISA bus
            ResourceProducer,        // bit 0 of general flags is 0
            PosDecode,
            MinFixed,                // Range is fixed
            MaxFixed,                // Range is Fixed
            Cacheable,
            ReadWrite,
            0x00000000,              // Granularity
            0x000a0000,              // Min
            0x000bffff,              // Max
            0x00000000,              // Translation
            0x00020000               // Range Length
            )
    

    I tried to add a resource producer for the D0000 region by creating an SDST with the following:

    DefinitionBlock ("SSDT.aml", "SSDT", 5, "MB", "ISA", 1)
    {
        External (_SB.PCI0, DeviceObj)
    
        Scope (_SB.PCI0)
        {
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                DwordMemory(
                     ResourceProducer,        // bit 0 of general flags is 0
                     PosDecode,
                     MinFixed,                // Range is fixed
                     MaxFixed,                // Range is Fixed
                     Cacheable,
                     ReadWrite,
                     0x00000000,              // Granularity
                     0x000d0000,              // Min
                     0x000dffff,              // Max
                     0x00000000,              // Translation
                     0x00010000               // Range Length
                     )
            })
        }
    }
    

    This was compiled and copied to %windir%\system32\acpitabl.dat as described here but unfortunately it didn't work.

    Instead I ended up modifying the DSDT for VirtualBox. This would normally mean re-compiling the whole application which is quite a task in itself so I just patched VBoxDD.dll to extend the top of the VGA memory region from BFFFF to DFFFF. My driver now loads correctly without any problems :smile:

    As an interesting side note, in trying to debug this I wrote a WDM driver that essentially does nothing but has an INF file with the same fixed resource requirements. I tried loading this on Windows XP and got the same result except that it was more helpful then Windows 10 by actually telling you which resource is causing the problem and why:

    "Memory range 000D0000 - 000DFFFF not available".

    Windows 10 just says:

    "No conflicts".


    I hope this followup helps someone if they attempt something similar in the future. I'm interesting to hear anyone's thoughts on where I went wrong with my SSDT and if this method can be made to work.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 26 Feb - 1 Mar 2024 Live, Online