Hi,
Returning to really ancient stuff: one legacy (NT4 style) driver that
runs fine on XP, fails to load on Win7.
HalAssignSlotResources returns STATUS_OBJECT_NAME_NOT_FOUND.
Three and a half years ago Tim Roberts reported the same problem on
Vista
(http://www.osronline.com/showThread.CFM?link=104499),
but thread ended abruptly without any additional info.
Can anybody shed some light on this?
(Needless to say, I’m it exactly the same situation as Tim was in 2007 -
product near end of life, not worth to write a new driver, but there’s
need to run some tests under Win7).
Best regards,
Alex Krol
You have been being lucky since Windows XP, this can happen all the way
back to then, that is when you were supposed to be PnP compliant. I’d
say make end of life sooner.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Alexander Krol” wrote in message
news:xxxxx@ntdev:
> Hi,
> Returning to really ancient stuff: one legacy (NT4 style) driver that
> runs fine on XP, fails to load on Win7.
> HalAssignSlotResources returns STATUS_OBJECT_NAME_NOT_FOUND.
> Three and a half years ago Tim Roberts reported the same problem on
> Vista
> (http://www.osronline.com/showThread.CFM?link=104499),
> but thread ended abruptly without any additional info.
> Can anybody shed some light on this?
> (Needless to say, I’m it exactly the same situation as Tim was in 2007 -
> product near end of life, not worth to write a new driver, but there’s
> need to run some tests under Win7).
>
> Best regards,
> Alex Krol
HalAssignSlotResources is, of course, deprecated since XP arrival, but
it is supposed to work. Well, PDEVICE_OBJECT parameter became mandatory
instead of optional, but with this change old stuff worked flawlessly on
XP and Server2003 - exactly as promised. Haven’t yet seen any official
Microsoft announcement that legacy stuff is unsupported on Win7 32 bit.
Best regards,
Alex Krol
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-445092-
xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, March 16, 2011 1:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Legacy driver on Win7: HalAssignSlotResources
returns STATUS_OBJECT_NAME_NOT_FOUND
You have been being lucky since Windows XP, this can happen all the
way
back to then, that is when you were supposed to be PnP compliant. I’d
say make end of life sooner.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Alexander Krol” wrote in message
> news:xxxxx@ntdev:
>
> > Hi,
> > Returning to really ancient stuff: one legacy (NT4 style) driver
> that
> > runs fine on XP, fails to load on Win7.
> > HalAssignSlotResources returns STATUS_OBJECT_NAME_NOT_FOUND.
> > Three and a half years ago Tim Roberts reported the same problem on
> > Vista
> > (http://www.osronline.com/showThread.CFM?link=104499),
> > but thread ended abruptly without any additional info.
> > Can anybody shed some light on this?
> > (Needless to say, I’m it exactly the same situation as Tim was in
> 2007 -
> > product near end of life, not worth to write a new driver, but
> there’s
> > need to run some tests under Win7).
> >
> > Best regards,
> > Alex Krol
Alexander Krol wrote:
Returning to really ancient stuff: one legacy (NT4 style) driver that
runs fine on XP, fails to load on Win7.
HalAssignSlotResources returns STATUS_OBJECT_NAME_NOT_FOUND.
Three and a half years ago Tim Roberts reported the same problem on
Vista
(http://www.osronline.com/showThread.CFM?link=104499),
but thread ended abruptly without any additional info.
Can anybody shed some light on this?
(Needless to say, I’m it exactly the same situation as Tim was in 2007 -
product near end of life, not worth to write a new driver, but there’s
need to run some tests under Win7).
There is no answer. HalAssignSlotResources is broken.
We traced this quite deeply. HalAssignSlotResources calls
PciAssignSlotResources, which calls PciProcessStartResources. When it
gets to the interrupt resource, it calls PciGetInterruptConnectionData,
which calls IoGetDevicePropertyData with
INTERRUPT_CONNECTION_DATA_PKEY. That calls PnpGetDevicePropertData,
which calls PnpOpenDevicePropertyKey, which calls
PnpOpenDevicePropertyNamespaceKey, which calls IopOpenRegisteryKeyEx,
which calls ZwOpenKey, and that call fails with
STATUS_OBJECT_NAME_NOT_FOUND.
Our theory was that the addition of MSI handling code in Vista
unintentionally broke legacy operations with interrupts.
We thought we could fix this by switching to IoReportDetectedDevice and
IoReportResourceForDetection, but that also hit a dead end. In the end,
we rewrote the startup code to be plug-and-play.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>
Alexander Krol wrote:
> Returning to really ancient stuff: one legacy (NT4 style) driver
that
> runs fine on XP, fails to load on Win7.
> HalAssignSlotResources returns STATUS_OBJECT_NAME_NOT_FOUND.
> Three and a half years ago Tim Roberts reported the same problem on
> Vista
> (http://www.osronline.com/showThread.CFM?link=104499),
> but thread ended abruptly without any additional info.
> Can anybody shed some light on this?
> (Needless to say, I’m it exactly the same situation as Tim was in
2007 -
> product near end of life, not worth to write a new driver, but
there’s
> need to run some tests under Win7).
There is no answer. HalAssignSlotResources is broken.
We traced this quite deeply. HalAssignSlotResources calls
PciAssignSlotResources, which calls PciProcessStartResources. When it
gets to the interrupt resource, it calls
PciGetInterruptConnectionData,
which calls IoGetDevicePropertyData with
INTERRUPT_CONNECTION_DATA_PKEY. That calls PnpGetDevicePropertData,
which calls PnpOpenDevicePropertyKey, which calls
PnpOpenDevicePropertyNamespaceKey, which calls IopOpenRegisteryKeyEx,
which calls ZwOpenKey, and that call fails with
STATUS_OBJECT_NAME_NOT_FOUND.
If ZwOpenKey is failing with STATUS_OBJECT_NAME_NOT_FOUND, could the
problem be mitigated with the creation of the ‘missing’ key? Or is that
just the first problem that blocks, with many further problems lying in
wait behind it?
James
James Harper wrote:
If ZwOpenKey is failing with STATUS_OBJECT_NAME_NOT_FOUND, could the
problem be mitigated with the creation of the ‘missing’ key? Or is that
just the first problem that blocks, with many further problems lying in
wait behind it?
We tried that route. It calls ZwOpenKey with a root handle of
0x80000100 and a key of “{f0e20f09-d97a-49a9-8046-bb6e22e6bb2e}”. The
meaning of the special root handle 0x80000100 is not documented. We
probably could have reverse engineered enough stuff to figure out where
that really points, but we decided that was too delicate, as the meaning
might change with an upgrade or service pack.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> James Harper wrote:
> If ZwOpenKey is failing with STATUS_OBJECT_NAME_NOT_FOUND, could the
> problem be mitigated with the creation of the ‘missing’ key? Or is
that
> just the first problem that blocks, with many further problems lying
in
> wait behind it?
We tried that route. It calls ZwOpenKey with a root handle of
0x80000100 and a key of “{f0e20f09-d97a-49a9-8046-bb6e22e6bb2e}”. The
meaning of the special root handle 0x80000100 is not documented. We
probably could have reverse engineered enough stuff to figure out
where
that really points, but we decided that was too delicate, as the
meaning
might change with an upgrade or service pack.
I’d guess the handle would be to the device properties (eg
HKLM\System\CurrentControlSet\Enum\PCI<device><instance>\Properties),
but yeah, it’s probably the tip of the iceberg and you’ll end up with
something that will blow up with the next service pack or hotfix etc.
James