Software Deployment

Hi Apena:

Here is the problem that I can figure out:

1. You have the cat file that is of no size 0 bytes
2. A cat file is used for security purposes or you can say for signed drivers and DPinst only accepts signed drivers. But as using /lm you have not modified the xml file with this switch <legacy mode />.
3. This means without this cat file you shall not be able to install the device driver since thats what DPInst demands for.
4. However you are able to install this thru the Hardware Wizard since that can install signed and unsigned drivers.

I think you can try attaching a Kernel Debugger to your OS and then set this envrionment variable _DFX_INSTALL_UNSIGNED_DRIVER set the value to 1 this would disable the difx to perform any security checks on the driver.
I shall try to look forward from Microsoft or Google for more information on how to install unsigned driver thru DPInst. In the meanwhile please revert back if you got any other queries.

Thank for replying..

1) - the cat file w/ 0 bytes does not seem to be a problem when using the HW wizzard.
2) According to Dpinst documentation from microsoft website dpinst supports unsigned drivers by using the /lm (legacy mode). I didnt know the dpinst.xml file needed to have the legacy mode tag in addition to running dpinst.exe w/ the /lm switch? From reading the doc you can either set the legacy flag to ON, either by using the switch and running dpinst or thru the xml file. I will try modifying the xml and see what happens..
4) What do you mean by: "I think you can try attaching a Kernel Debugger to your OS and then set this envrionment variable _DFX_INSTALL_UNSIGNED_DRIVER set the value to 1 this would disable the difx to perform any security checks on the driver. " How do I attach a kernel debugger? I know how to do the env. variable but not sure on the debugger.

Hi Apena:

To turn on or attach a debugger you need to do the following:

1. Find and open the Boot.ini file
2. In the [Operating systems] section of the file just type /debug at the end of the line , your final file should look like this:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /debug

3. Save the Ini and set the variable that have been discussed earlier

Now this would turn on your Kernel Debbuger, once this is on then DPinst would not look for signed or unsigned drivers.

Bhupesh,

I set the environment variable and added the entry to the boot.ini. Rebooted. Double-clicking in the dpinst.exe or running it from a command line w/ the lm switch did not do anything. I am still getting the error in the dpinst.log shown above.

Hi Apena:

Have a look at this message till that time I shall try to replicate the problem at my end:

Click here

Bhupesh,

Have you had time to recreate the problem? I can provide you w/ the 0 KB .cat file and other drivers if you want to really try using DPinst. Send me an email address to send you the files.

thanks.

Hi Apena:

I believe you must have got my email?

To make the long story short. I contacted the vendor and they didnt provide me w/ a signed catalog file or one that wasnt empty. I went back and forth w/ Microsoft on this and we ended up rewriting the .inf file so that dpinst will get past the problems. The problem was that although dpinst completed, upon pluggin the device the Found New HW Wizzard will popup. Obviously even though dpinst finished, and the driver was preinstalled, it was still not being recognized correctly by the OS. I still needed to go thru the different HW Wizzard prompts to complete the installation successfully. The goal here was to automate the driver installation but it was obvious at this point that user intervention will be required for this to work.

At the end, our solution was to install the drivers and sw manually. Only 2 people will be using this app in our company so it made more sense to us to do it this way. Below, I am posting Microsofts technical explanation on why dpinst did not work for this scenario. I hope it helps as others read thru these posts.

I also want to thank Bhupesh (wiseapp) from this forum for going back and forth on this w/ me.

Here is the Microsoft response I got:

Greetings,

This is the general problem with unsigned drivers. To answer your questions in reverse…

The technical explanation of why DPINST can not install these drivers silently is because they are unsigned. This is OS behavior and is by design. Only signed drivers can be installed silently. You can locally change the security policy so that the OS will not care, but that does not help commercial distribution.
The original package you received for the drivers is broken (invalid(zero size) CAT file). The CAT file contains the digital signatures of various files, most importantly, the INF and driver files.
DPINST uses a different code path for installing device drivers than the Hardware Wizard. The Hardware Wizard, even on broken packages, will allow the installation via user intervention. DPINST does not.
Because of this, there is no advantage of using DPINST to install unsigned drivers silently.

As we spoke about before, this is not your fault. There are two elements that complicates this case. (1) OS design does not allow installation of unsigned drivers silently and (2) The manufacturer delivered to you a broken (unsigned) package and will not fix it. This forces both of us to use the lowest common denominator - OS behavior with unsigned drivers. DPINST was designed to simplify the installation of signed drivers, including pre-installation. But if the packages are unsigned, broken, etc. then we start seeing the behavior you are experiencing.

For specific documentation, I give you a link that describes what’s called server-side install. Which can only be used by signed drivers. Once a problem is detected, unsigned for example, client-side install is invoked. This takes on the rights of the currently signed on user and UI is shown. A silent installation must meet all of the following criteria. If at any point this breaks, no matter what program is trying to install the packages, UI will appear. How the program deals with the UI will differ. For instance, DPINST will fail the install completely whereas the Hardware Wizard will allow it after user interaction.

The following can be found in the DDK under the search term “server side install” -> Device Installation Types

Device Installation Types
Windows defines two types of device installations: server-side and client-side. Because they do not require user intervention by an administrator, server-side installations are more desirable than client-side installations.

Server-side Installations
A server-side installation is a device installation that can be handled entirely by the system's user-mode and kernel-mode PnP manager components. A server-side installation can occur only if:

The device can be detected by a bus driver, which then must notify the PnP manager.
The PnP manager can find an INF file containing a hardware ID that matches that of the device.
The device's INF file and drivers are signed (see Driver Signing).
SetupAPI can locate all of the device's drivers without prompting the user for media locations. (This means the drivers are included "in-box" with the operating system, a vendor-supplied driver was previously installed, or vendor-supplied driver files have been "preinstalled" so SetupAPI can locate them during the actual installation (see Preinstalling Driver Files).
The device's class installer and co-installers do not display property pages at the end of the installation operation.
The device's INF file has not marked the device as requiring an interactive installation (by specifying InteractiveInstall in an INF ControlFlags section).
RunOnce registry entries consist only of calls to rundll32.exe.
Server-side installations do not display any user interface and do not require an administrator to be logged on. (The term "server-side" is used because installation can be accomplished by the system's PnP manager without a user-mode "client" making calls into the PnP manager.)

Client-side Installations
A client-side installation is a device installation that requires communication with a user. A client-side installation occurs if any of the following are true:

The PnP manager cannot find an INF file containing a hardware ID that matches that of the device.
The PnP manager cannot locate all the required driver files.
The device's INF or driver files are not signed.
SetupAPI has to display any form of user interface, such as prompting the user for media locations.
A class installer or co-installer displays property pages at the end of the installation operation.
The device, bus, or bus driver does not support Plug and Play (PnP).
Client-side installations require use of installation "client" software, such as the Add Hardware wizard, the New Device DLL, or a vendor-supplied device installation application. This client software installs the device by making calls to SetupAPI, which in turn calls the PnP manager when necessary. (The PnP manager is considered to be the installation operation's "server side.")

I hope this answers your questions. As long as you have to deal with a broken package, the results will remain the same. If they can resign their package, you will regain silent installation ability.

Best regards,

Daniel Whitaker
Escalation Engineer - Microsoft DDK & WDK Support