Trouble Installing Driver Using DIFxApp
in [Device Drivers]
|
Prev: wdf 5483 question
Next: IOCTL_USB_USER_REQUEST
From: Abhishek R [MSFT] on 12 Sep 2006 15:46 DIFxApp 2.01 and later versions support elevated installs when a non-admin user who has logged in triggers the install of a package that has previously been "approved" by an admin user for elevated installs. I've tried this out with success. But it seems like you're seeing the problem only when the user is not logged in or a different user is logged in. I've never tried that out, so I'm not sure what's going on. Sorry. <sm_spc_2(a)hotmail.com> wrote in message news:1158052976.803508.235580(a)p79g2000cwp.googlegroups.com... > Atul and I are both dealing with the same problem from different ends > (I wrote the MSI, he's deploying it). > > Now we used DifXApp for a related product and it worked OK, but it was > an earlier version of difxapp (2.0). The log file differences are as > follows... > > === Failed installation=== > DIFXAPP: InstallDriverPackages > DIFXAPP: 'CustomActionData' property 'DIFxApp Version' is 2.01. > DIFXAPP: 'CustomActionData' property 'UI Level' is 2. > DIFXAPP: 'CustomActionData' property 'componentId' is > {B5163EB8-0919-4E86-915C-3C9FA08CE2E4}. > DIFXAPP: 'CustomActionData' property 'componentPath' is C:\Program > Files\Symantec\Enterprise Vault\drivers\. > DIFXAPP: 'CustomActionData' property 'flags' is 0x14. > DIFXAPP: 'CustomActionData' property 'installState' is 2. > DIFXAPP: 'CustomActionData' property 'ProductName' is Enterprise Vault > File System Archiving. > DIFXAPP: 'CustomActionData' property 'ManufacturerName' is Symantec. > DIFXAPP: ERROR 0x2 encountered while opening install-info subkey for > component '{B5163EB8-0919-4E86-915C-3C9FA08CE2E4}' > DIFXAPP: InstallDriverPackages failed with error 0x2 > > === Successful install === > DIFXAPP: InstallDriverPackages > DIFXAPP: 'CustomActionData' property 'DIFxApp Version' is 2.0. > DIFXAPP: 'CustomActionData' property 'UI Level' is 3. > DIFXAPP: 'CustomActionData' property 'componentId' is > {A9DA0C37-7E86-454A-9880-759708944512}. > DIFXAPP: 'CustomActionData' property 'componentPath' is C:\Program > Files\VERITAS\Storage Exec\bin\FSFilter\. > DIFXAPP: 'CustomActionData' property 'flags' is 0xC. > DIFXAPP: 'CustomActionData' property 'installState' is 2. > DIFXAPP: 'CustomActionData' property 'ProductName' is Symantec Storage > Exec. > DIFXAPP: 'CustomActionData' property 'ManufacturerName' is Symantec > Corporation. > DIFXAPP: INFO: ENTER: DriverPackageInstallW > DIFXAPP: INFO: FileScreenFilter.inf: Skipping DFX signature > verification. > DIFXAPP: INFO: Copying 'FileScreenFilter.inf' to driver store... > DIFXAPP: INFO: Installing INF file > "C:\WINDOWS\system32\DRVSTORE\FileScreen_D5F4CE42F3F9A7ABD5F75BE07851270F290ABF8B\FileScreenFilter.inf" > of Type > DIFXAPP: INFO: installing class filter > 'C:\WINDOWS\system32\DRVSTORE\FileScreen_D5F4CE42F3F9A7ABD5F75BE07851270F290ABF8B\FileScreenFilter.inf' > DIFXAPP: SUCCESS:Installation completed with code 0x0. > > > ==== > The differences appear to be in the flags and the UILevel > For the failed package the following bits are set: > 4 - Don't create ARP entry > 16 - Do uninstall > For the successful intallation the bits are > 4 - no ARP > 8 - allow unsigned > > So it's possible that the problem lies with the driver signature > verification. Checking the driver signature isn't a ship killer for the > application, but it would be nice to have, especially if driver signing > is required for Vista. > > Arguably the UI level may also be significant if difxapp is trying to > interact with the user (UI level3 = /qb) in the failed installation. > Maybe totally suppressing the UI (/qn) will have an effect as well. >
From: minorguy on 12 Sep 2006 16:36 "sm_spc_2(a)hotmail.com" wrote: > We're experiencing the same error, but the circumstances are slightly > different. > > Our package is pushed to a remote host by a wizard and executed on the > remote target, at which point we get the error > DIFXAPP: ERROR 0x2 encountered while opening install-info subkey for > component '{B5163EB8-0919-4E86-915C-3C9FA08CE2E4}' > DIFXAPP: InstallDriverPackages failed with error 0x2 > and the whole thing rolls back. > > However, if you just run the msi package locally under the admin > account it all works fine. > Alos, the problem goes away if you use the AlwaysInstallElevated policy > > Difxapp apparently creates a number of temporary files that it needs to > do its thing - at least that's my educated guess, as the framework has > another custom action (MsiCleanupOnSuccess) that's used for tidying up > after installfinalize. > > Now the MsiProcessDrivers action is immediate and therefore runs under > the context of the *user*. When the customaction that actually does the > driver installation runs (MsiInstallDrivers) it's set to run in > *system* context (3072 +1). > > 0x2 is a file access error, so it may be possible that under certain > circumstances the MsiInstallDrivers difxapp CA is somehow unable to > access the temporary files that were created by the earlier > (MsiProcessDrivers) CA. > > Our issue manifests itself if the user under which the installation is > running is not currently logged into the target device, so if difxapp > is writing its temp files into a location that depends on the user > profile, it might come unstuck. > > This is all just theorization and doesn't offer any solutions - anyone > else got any ideas about what's going on and what to do?? > > Thanks very much for the information. You say that the problem goes away if the AlwaysInstallElevated policy is set in the registry. Do you mean that you can then successfully install remotely? Why isn't this a solution? I assume it's because you can't change these keys in the target machine's registry from the remote machine because it would be a big security hole, true? If there were a way to temporarily change it (say, if the person doing the push install had network admin rights) then maybe it would work. But I currently don't know how to do that. Since the error in the log is “DIFXAPP: ERROR 0x2 encountered while opening install-info subkey for component“ refers to a “subkey”, I was thinking that it might be getting stuck accessing the registry somehow. Maybe the 0x2 file error code is used not only for things that are strictly files but for anything accessed like a file, such as the registry, a pipe, a device, etc.
From: Ferdous Rubaiyat on 12 Sep 2006 17:54 Hi Atul, I am in DIFx test team. Could you please let me know how I can reproduce this problem at my side? I would be glad to find the root cause of this issue. Thanks, Ferdous Rubaiyat "Atul" <atuldpatil(a)gmail.com> wrote in message news:1158043322.490313.180210(a)i3g2000cwc.googlegroups.com... > > > Hi, > > Even I am also facing exactly SAME trouble with remote installation. > If same user has logged in on remote machine, DIFXAPP succeeds, > but if different user OR no user has logged in, DIFXAPP fails. > So I feel DIFXAPP has problem related to impersonation. > > I am using 'DIFxApp Version' is 2.01. > > DIFXAPP: 'CustomActionData' property 'DIFxApp Version' is 2.01. > > Please suggest me some way out on this as I am stuck on this issue. > > Thanks, > Atul > > > Abhishek R [MSFT] wrote: >> which version of DIFxApp are you using? >> >
From: Atul on 5 Oct 2006 08:54 Sorry for late reply. Finally I got the solution. In my case, I was copying msi onto remote system and was calling msiexec using CreateProcess. The msi was installing driver using DIFXAPP, it was failing if user loggged in on remote system is different that the user connecting to remote machine (or even if nobody was logged in on remote system, then also it was failing). However if the same user was logged in, then installation was going successful. Then I got the trick. Instead of using CreateProcess, use CreateProcessWithLogon function. This function "logs in" on remote system and then creates process on behalf of the logged in user. Hence it is as good as you were actually logged in and doing something on that system. This solution works fine and our QA have been testing the remote installation on different platforms. Its almost three weeks after I implemented this solution and no problems so far till now have been repprted by QA. cheers, Atul D. Patil minorguy wrote: > > Thanks very much for the information. You say that the problem goes away if > the AlwaysInstallElevated policy is set in the registry. Do you mean that you > can then successfully install remotely? Why isn't this a solution? I assume > it's because you can't change these keys in the target machine's registry > from the remote machine because it would be a big security hole, true? If > there were a way to temporarily change it (say, if the person doing the push > install had network admin rights) then maybe it would work. But I currently > don't know how to do that. > > Since the error in the log is "DIFXAPP: ERROR 0x2 encountered while opening > install-info subkey for component" refers to a "subkey", I was thinking that > it might be getting stuck accessing the registry somehow. Maybe the 0x2 file > error code is used not only for things that are strictly files but for > anything accessed like a file, such as the registry, a pipe, a device, etc.
From: minorguy on 5 Oct 2006 14:30
"Atul" wrote: > > Sorry for late reply. > > Finally I got the solution. In my case, I was copying msi onto remote > system and was calling msiexec using CreateProcess. The msi was > installing driver using DIFXAPP, it was failing if user loggged in on > remote system is different that the user connecting to remote machine > (or even if nobody was logged in on remote system, then also it was > failing). However if the same user was logged in, then installation was > going successful. Then I got the trick. > > Instead of using CreateProcess, use CreateProcessWithLogon function. > This function "logs in" on remote system and then creates process on > behalf of the logged in user. Hence it is as good as you were actually > logged in and doing something on that system. > > This solution works fine and our QA have been testing the remote > installation on different platforms. Its almost three weeks after I > implemented this solution and no problems so far till now have been > repprted by QA. > > cheers, > Atul D. Patil > Thanks very much for that info, Atul! In my case, the customer solved the problem on their own. Although, I never learned what their solution was because they're a few layers (of business) separated from me. But I will definately hang on to your solution for further reference since it's likely this sort of problem could come up again somewhere. |