FBA driver install order

[Lucvdv]

Is there something like the "Phase" setting in an FBA generic command, that
can be applied to driver installation?


I have to install a driver after the parallel port driver has already been
installed and started (this driver connects to the parallel port driver, it
needs it to be running when it is installed to initialize some of its own
parameters).

I created a component based on the INF file, but it isn't properly
installed: the service key in the registry is there, but with
InitStartFailed=1.

If I include the Add Hardware control panel and reinstall the driver after
FBA has finished, through the same INF file that FBA has used, it works.

 

[Slobodan Brcin \(eMVP\)]

Hi Lucvdv,

If this was hardware driver then PnP would install it by default only after parallel driver was starter and enumerated device
connected to it.
But I think that your driver is software driver that in not hardware PnP, am I right?

In this case you had to preinstall driver from your component trough registry, right? You can set in services registry branch Start
value to 4 so your driver won't execute during the FBA. At end phase of FBA you can change Start value to 3 or some other required
value and thus enable it on next boot.

Regards,
Slobodan

PS:
Your software driver is purely written since it do not wait for parallel port to be available.
Also if this is hardware driver let us see inf file and give us more info about the device it handle.

 

[Lucvdv]

Hi Lucvdv,

If this was hardware driver then PnP would install it by default only after parallel driver was starter and enumerated device
connected to it.
But I think that your driver is software driver that in not hardware PnP, am I right?

Right.

It drives external hardware connected to the parallel port, but it connects
to the parport driver and does everything through there.

In this case you had to preinstall driver from your component trough registry, right?

Not really: it's installed through an INF file, and it does get its own
device key in \enum\root (just like modems and spooler, for example).

You can set in services registry branch Start
value to 4 so your driver won't execute during the FBA. At end phase of FBA you can change Start value to 3 or some other required
value and thus enable it on next boot.

Regards,
Slobodan

PS:
Your software driver is purely written since it do not wait for parallel port to be available.
Also if this is hardware driver let us see inf file and give us more info about the device it handle.

It has parport listed in its dependencies, so it should never be started if
the ParPort driver isn't running.

If it would be started before the parallel driver has fully initialized (so
it can't connect, which happens on XP, but didn't on W2K), it enters a wait
and retries every 15 seconds until it works or until it times out after a
couple of minutes.

But in this case it went wrong _before_ that: it was never started if
installed during FBA, its device key in enum\root was not created.


I tried to install it through devcon.exe in an FBA generic command, but
that has only lead to more headaches:

FBALOG:
: 17:18:57 PM - [FBALaunch] C:\WINDOWS\system32\devcon.exe install C:\Temp\ParComm.Inf ParComm (ExitCode: 0x2)

I suppose Exit code 2 == win32 error code 2 == file not found, but there
are only two files involved, .inf and .sys, and both existed in C:\Temp.

This is at the end of FBA (phase 8502), the next thing in the logfile is
the EWF initialization. In phase 8501 I enabled the parallel port
interrupt and the ConnectInterrupt IOCTL, but those aren't necessary to get
my driver installed, only to use it.

When I copy & paste the command from the logfile to a CMD prompt after FBA
has finished, it succeeds. This works regardless of whether the current
directory is system32 or C:\Temp -- but it prompts me with an "unsigned
driver" dialog, which I can't have either.



I know the driver works because I've been using it for some time in XPe
SP0, but there I installed it manually between FBA and cloning. Now I
wanted to create a target where everything works after FBA finishes, so I
can clone pre-FBA.

My next attempt (tomorrow) will be by running a batch file during the first
boot after FBA.

If that doesn't work, I'll have to find a way to clone disks that doesn't
destroy the EWF partition (that's the problem I had with ghost: even when
keeping partition sizes identical and by cloning the EWF partition in byte
mode, EWF didn't work on the final disks - which I found out much too late,
because there was no way to check if EWF was still working after my own app
was made the shell).

 

[Slobodan Brcin \(eMVP\)]

Hi Lucvd,

I see well you can always do what I told you about preinstalling driver by filling registry entries from your component and leaving
driver disabled by start value 4 until the last FBA phase when you would change it to required value. This would help you.

I did not understand how you wait for parallel driver to become available.
You can't do simple wait unless you have created independent work thread.

It has parport listed in its dependencies, so it should never be started if
the ParPort driver isn't running.

This is used for driver load purpose order not for actual start which can be done ages later.

For making one driver wait for another there is a intended mechanism that do not rely on time.
IoRegisterBootDriverReinitialization
IoRegisterDriverReinitialization

Regards,
Slobodan

Hi Lucvdv,

If this was hardware driver then PnP would install it by default only after parallel driver was starter and enumerated device
connected to it.
But I think that your driver is software driver that in not hardware PnP, am I right?

Right.

It drives external hardware connected to the parallel port, but it connects
to the parport driver and does everything through there.

In this case you had to preinstall driver from your component trough registry, right?

Not really: it's installed through an INF file, and it does get its own
device key in \enum\root (just like modems and spooler, for example).

You can set in services registry branch Start
value to 4 so your driver won't execute during the FBA. At end phase of FBA you can change Start value to 3 or some other required
value and thus enable it on next boot.

Regards,
Slobodan

PS:
Your software driver is purely written since it do not wait for parallel port to be available.
Also if this is hardware driver let us see inf file and give us more info about the device it handle.

It has parport listed in its dependencies, so it should never be started if
the ParPort driver isn't running.

If it would be started before the parallel driver has fully initialized (so
it can't connect, which happens on XP, but didn't on W2K), it enters a wait
and retries every 15 seconds until it works or until it times out after a
couple of minutes.

But in this case it went wrong _before_ that: it was never started if
installed during FBA, its device key in enum\root was not created.


I tried to install it through devcon.exe in an FBA generic command, but
that has only lead to more headaches:

FBALOG:
: 17:18:57 PM - [FBALaunch] C:\WINDOWS\system32\devcon.exe install C:\Temp\ParComm.Inf ParComm (ExitCode: 0x2)

I suppose Exit code 2 == win32 error code 2 == file not found, but there
are only two files involved, .inf and .sys, and both existed in C:\Temp.

This is at the end of FBA (phase 8502), the next thing in the logfile is
the EWF initialization. In phase 8501 I enabled the parallel port
interrupt and the ConnectInterrupt IOCTL, but those aren't necessary to get
my driver installed, only to use it.

When I copy & paste the command from the logfile to a CMD prompt after FBA
has finished, it succeeds. This works regardless of whether the current
directory is system32 or C:\Temp -- but it prompts me with an "unsigned
driver" dialog, which I can't have either.



I know the driver works because I've been using it for some time in XPe
SP0, but there I installed it manually between FBA and cloning. Now I
wanted to create a target where everything works after FBA finishes, so I
can clone pre-FBA.

My next attempt (tomorrow) will be by running a batch file during the first
boot after FBA.

If that doesn't work, I'll have to find a way to clone disks that doesn't
destroy the EWF partition (that's the problem I had with ghost: even when
keeping partition sizes identical and by cloning the EWF partition in byte
mode, EWF didn't work on the final disks - which I found out much too late,
because there was no way to check if EWF was still working after my own app
was made the shell).

 

[Lucvdv]

Hi Lucvd,

I see well you can always do what I told you about preinstalling driver by filling registry entries from your component and leaving
driver disabled by start value 4 until the last FBA phase when you would change it to required value. This would help you.

I did not understand how you wait for parallel driver to become available.
You can't do simple wait unless you have created independent work thread.

That's how I did it.

For making one driver wait for another there is a intended mechanism that do not rely on time.
IoRegisterBootDriverReinitialization
IoRegisterDriverReinitialization

Thanks, I didn't know about these two.
Drivers aren't something I do every day (or even every year), I started
from a prototype created by the tools that come with Walter Oney's book
"Programming the Windows Driver Model" and just added in my own
functionality.

The mechanism isn't perfect, but it always did the job well enough because
it's only used for a very specific application, it won't ever be installed
on a generic PC.

This is getting a bit OT for the group, but basically, starting the driver
should _always_ succeed, even if there is no parallel port.

It adds a new device to the system, but instead of controlling real
hardware, it attaches to the parport driver as an intermediate driver.

Here it must have failed early on (probably something in the AddDevice
routine, IoCreateDevice or so). I'd have to connect a kernel debugger and
examine debug output to see what really went wrong.

The work thread is started in StartDevice (IRP_MN_START_DEVICE, i.e. after
AddDevice), and tries to attach to the parport driver, retrying every 15
seconds. If it can't do this in 10 attempts, the work thread stops. The
driver isn't stopped at this time, but I/O attempts will keep returning a
status indicating 'no parallel port'.

 

[Slobodan Brcin \(eMVP\)]

Hi Lucvdv,

Here it must have failed early on (probably something in the AddDevice
routine, IoCreateDevice or so). I'd have to connect a kernel debugger and
examine debug output to see what really went wrong.

Well I can't imagine writing or testing drivers without debugger, so yes you should configure it. Since it is a software driver
there are small changes that it failed in AddDevice or IoCreateDevice if you have preinstalled it correctly. (You will see this from
debugger).

The work thread is started in StartDevice (IRP_MN_START_DEVICE, i.e. after
AddDevice), and tries to attach to the parport driver, retrying every 15
seconds. If it can't do this in 10 attempts, the work thread stops. The
driver isn't stopped at this time, but I/O attempts will keep returning a
status indicating 'no parallel port'.

I assume that you use IoCreateFile from inside of thread to open paralel driver, right?
Since you made this for XPe purposes there is no harm if you try infinitely to open paralel port. There is no need to terminate
thread.

Regards,
Slobodan

 

[Lucvdv]

I assume that you use IoCreateFile from inside of thread to open paralel driver, right?

No, there's some more required because it installs its own interrupt
handler for the port interrupt (it has to handle very fast incoming data
without missing a byte and without polling).
It uses IoAttachDeviceToDeviceStack to attach itself in the driver chain.

All I/O later only accesses data through the interrupt handler, the real
parport driver is sort of put out of play.

But this all works ;-)


In the mean time I tried further along the devcon.exe path, and it's
beginning to look stranger and stranger.

I wrapped it in [cmd.exe /k], so FBA pauses until the cmd shell is closed.
The FBA log entry is now:

: 17:12:20 PM - [FBALaunch] C:\WINDOWS\system32\cmd.exe /K devcon.exe install C:\Temp\ParComm.Inf ParComm (ExitCode: 0x0)

The exit code 0 comes from cmd.exe, devcon still fails.
But when I type in the exact same devcom command in the same cmd shell
immediately thereafter, it succeeds.


Also, because the driver has been in use long enough in XPe SP0, I think
it's more likely my INF file where the error is than the driver itself.

In the SP0 setup, the driver was installed manually between FBA and
cloning. Now it's an upgrade, and cloning has to take place before FBA.

 

[Lucvdv]

I wrapped it in [cmd.exe /k], so FBA pauses until the cmd shell is closed.
The FBA log entry is now:

: 17:12:20 PM - [FBALaunch] C:\WINDOWS\system32\cmd.exe /K devcon.exe install C:\Temp\ParComm.Inf ParComm (ExitCode: 0x0)

The exit code 0 comes from cmd.exe, devcon still fails.

I put the command in a batch file, and started that through cmd /K.

It echoed "Devcon failed."

Started the batch file manually, immediately after it failed.

It succeeded.

 

[Slobodan Brcin \(eMVP\)]

Hi Lucvdv,

You made some obscure driver :-(
You should not attach to parallel driver in that way unless if you are writing upper filter driver. But then you would install it
differently. (It would be automatically installed and started when parallel driver is installed)
Basically you should change either inf file that install parallel driver so it install you driver as well automatically. Or register
your driver as upper class filter driver from TD at branch:
CurrentControlSet\Control\Class\{4D36E978-E325-11CE-BFC1-08002BE10318}\UpperFilters REG_MULTI_SZ (Yourdriver name)

Regards,
Slobodan

PS: Read about filter driver in Walters book. Also read trough DDK.

I wrapped it in [cmd.exe /k], so FBA pauses until the cmd shell is closed.
The FBA log entry is now:

: 17:12:20 PM - [FBALaunch] C:\WINDOWS\system32\cmd.exe /K devcon.exe install C:\Temp\ParComm.Inf ParComm (ExitCode: 0x0)

The exit code 0 comes from cmd.exe, devcon still fails.

I put the command in a batch file, and started that through cmd /K.

It echoed "Devcon failed."

Started the batch file manually, immediately after it failed.

It succeeded.

 

[Lucvdv]

Hi Lucvdv,

You made some obscure driver :-(
You should not attach to parallel driver in that way unless if you are writing upper filter driver. But then you would install it
differently. (It would be automatically installed and started when parallel driver is installed)
Basically you should change either inf file that install parallel driver so it install you driver as well automatically. Or register
your driver as upper class filter driver from TD at branch:
CurrentControlSet\Control\Class\{4D36E978-E325-11CE-BFC1-08002BE10318}\UpperFilters REG_MULTI_SZ (Yourdriver name)

IIRC (It's been a few years) I started it as a filter driver in Walter's
MDMWIZ tool, so maybe I'm just installing it the wrong way.

I do remember that I tried three different approaches, including at least
one filter and at least one function driver, and only this one fully
worked. A function driver replacing the parallel driver can't be used
without modifying windows itself (I was testing it in Win2000 at the time:
it just reinstalled the parallel port driver at the next boot).
Another approach didn't work because the parallel driver wouldn't leave the
port alone: the data lines should always remain inputs for this
application, but it reset them to outputs behind my back and then switched
them back to input when I accessed the port again.


Anyway, it works now (finally

I included a delay at the start of the batch file, before starting devcon:
it succeeds.


I can't explain why the delay is necessary, unless FBA would start generic
commands with different phase values simultaneously instead of waiting with
the higher phase until the lower has finished.

There are two GC's, at phase 8501 and 8502, both with flags=0 and
timeout=0. The one at 8501 sets a registry value that's needed for devcon
to work without popping up an "unsigned driver" dialog, the one at 8502 is
devcon.


BTW: the registry value is HKLM\Software\Microsoft\Driver Signing\Policy.

Do you know a way to switch it to "silently succeed" in TD? Especially
because you normally _can't_ change it by just hacking the registry value.

I found no way in TD (the driver signing UI component only allows you to
set it _after_ FBA). Adding the registry value in TD didn't work: even at
build order 32767, it was reset before the build finished.

Then I loaded the generated SOFTWARE file in regedit and changed it there
before copying to the target disk: FBA reset it again.

In the end I found no other solution than to set it in an FBA GC.

 

[Lucvdv]

Hi Lucvdv,

You made some obscure driver :-(

I know, but it works under Win2000, XP and XPe, so I think it's not that
obscure again, especially because the parallel driver structure changed
between W2k and XP

And I forgot: thanks for the help.

 

[Slobodan Brcin \(eMVP\)]

Hi,

Filter driver should work, but this is irrelevant since you already made a driver, and also you use it on so low level that true
filter driver alone can't help you anyhow.

I do not understand why function driver did not install for you on W2K, XP, but it might be something related to signing policies.
Anyhow on XPe you can remove signing component so it won't bother you again with notifications.
Also you can set VID, PID to do better match to your function driver then MS generic IDs use for parport driver.
This way your driver will own parallel port for its own usage and there will be no MS driver. (Also you do not need to put MS
parport driver at all in XPe )

Regards,
Slobodan