Topic: Driver Package Installer strange behavior under x64 builds  (Read 7729 times)

Driver Package Installer strange behavior under x64 builds
« on: October 07, 2012, 08:26:39 PM »

Aeolis

  • Chef
  • ***
  • Location: Rio de Janeiro, Brazil
  • Date Registered: Oct 2012
  • Posts: 134
Hello folks,
   
I have being experiencing a strange behavior with the Driver Package Installer and Driver Integration scripts under x64 builds.

I have split my drivers (they are all download from DriverPacks.net) for PE builds into two groups: the most important (chipset, mass storage, lan etc.) I have set to be integrated using the Driver Integration script and the less important (basically graphic card) I have set to be integrated using the Driver Package Installer script.

I’ve set Driver Integration script to run at startup and Driver Package Installer script to run manually (on demand through desktop shortcut).

Under x86 builds it works like a charm, perfectly (I click the desktop shortcut, the screen blinks and picture get resized accordingly to my monitor and graphic card resolution 1920x1080). But under x64 builds my graphic card driver didn’t get installed. I click the desktop shortcut, the screen blinks and nothing happens.

I thought it could be a problem with the driver, so I’ve set my graphic card driver to be installed using Driver Integration script instead of Driver Package Installer script. It worked. It seems that the Driver Integration script can handle my graphic card installation while the Driver Package Installer script cannot.

After studying this problem a bit further I’ve tried to use the Windows built-in Device Manager to install my graphic card and got the error presented in the attached picture. A rough translation of the error message would be “The resource loader cache doesn't have loaded MUI entry.”.

I would like to remember that this problem only occurs on x64 builds, everything is fine on x86 builds. So I think that maybe there is some missing .mui file in the x64 build that prevents my graphic card driver to be installed using the Driver Package Installer script.

Could you help me here? 

Best regards,

Aeolis

Re: Driver Package Installer strange behavior under x64 builds
« Reply #1 on: October 11, 2012, 09:46:29 PM »

Aeolis

  • Chef
  • ***
  • Location: Rio de Janeiro, Brazil
  • Date Registered: Oct 2012
  • Posts: 134
Hello folks,

I am working hard on debugging this problem, but I need some help here. Any tips on find the missing dependencies or missing executable that could lead to the mentioned problem?

Best regards,

Aeolis

Re: Driver Package Installer strange behavior under x64 builds
« Reply #2 on: October 12, 2012, 08:24:38 AM »

was_JFX

  • Code Baker
  • Grand Chef
  • *****
  • Date Registered: Dec 2010
  • Posts: 1074
Driver install is always logged in X:\Windows\inf\setupapi.dev.log
Compare both logs after install of the driver.

Use Process Monitor, set a filter for only CreateFile API and look for "not found" results.

If both not helps to find something copy all *.mui files to their respected locations.

Re: Driver Package Installer strange behavior under x64 builds
« Reply #3 on: October 12, 2012, 05:25:50 PM »

Aeolis

  • Chef
  • ***
  • Location: Rio de Janeiro, Brazil
  • Date Registered: Oct 2012
  • Posts: 134
Hello folks,

Thank you for your attention JFX :thumbsup:. Attached to this post is the "setupapi.dev.log" file as you requested. I have made a x64 build and put my graphic card driver with Driver Package Installer. I have made two attempts of installing the driver "nv_disp.inf" first using the [cmd: "X:\windows\System32\dpinst.exe" /s /path "Y:\DriverPacks"] command and the second with ["X:\windows\system32\mmc.exe" X:\windows\system32\devmgmt.msc] command. On both attempts as you can see in the "setupapi.dev.log" file the process was unable to copy one file to the FileRepository driver folder. This one failure prevented system from creating the right driver folder and I think that is the main problem.

The weird part is that on x86 builds the graphic card driver can be installed using both Driver Package Installer and Driver Integration scripts without any issues. However on x64 builds the graphic card driver can be installed only using the Driver Integration script, when using the Driver Package Installer on x64 builds I have the problem already mentioned.

I hope it helps.

Best regards,

Aeolis

Re: Driver Package Installer strange behavior under x64 builds
« Reply #4 on: October 12, 2012, 05:44:52 PM »

was_JFX

  • Code Baker
  • Grand Chef
  • *****
  • Date Registered: Dec 2010
  • Posts: 1074
There is a out of disk space error

Quote
!!!  sto:           Failed to copy file 'nvcompiler.dll'. Error = 0x00000070

Try to increase "FBWF cache size" in 2 - Shell & Config plugin.
Personally I would always recommand to set it to 512 MB for x64 builds.

Re: Driver Package Installer strange behavior under x64 builds
« Reply #5 on: October 12, 2012, 06:01:14 PM »

Aeolis

  • Chef
  • ***
  • Location: Rio de Janeiro, Brazil
  • Date Registered: Oct 2012
  • Posts: 134
Hello folks,

JFX it's set to 512 MB. I always use 512 MB for both x86 and x64 builds. The "out of disk space error" makes no sense at all for me :confused:. Why would the Driver Integration script (which store the drivers inside the .WIN file) be able to expand the driver (including my graphic card driver) and install without problem on x64 builds and the Driver Package Installer script (which post-boot install the driver) be not not able to do that on x64? I am really  :confused:.

Thank you again JFX :thumbsup:.

Best regards,

Aeolis


Re: Driver Package Installer strange behavior under x64 builds
« Reply #6 on: October 12, 2012, 07:04:05 PM »

was_JFX

  • Code Baker
  • Grand Chef
  • *****
  • Date Registered: Dec 2010
  • Posts: 1074
Well,

driver integration only copies the driver 1 time (from driverstore to system32 and drivers folder)

driver package copies it 3 times

1. to temp folder
2. to driver cache folder
3. to system32 and drivers folder

If I install current ATI driver via package installer, I lose temporary 230 MB from my X: drive

Re: Driver Package Installer strange behavior under x64 builds
« Reply #7 on: October 12, 2012, 07:14:40 PM »

Aeolis

  • Chef
  • ***
  • Location: Rio de Janeiro, Brazil
  • Date Registered: Oct 2012
  • Posts: 134
Hello folks,

JFX I think I have understood you explanation. So, there is no fix for the issue? If I want to install my graphic card driver on x64 builds it must be done by the Driver Integration script, isn't it?

Just for future reference:

In my scenario I have verified that regarding my graphic card driver (nVidia GTX 580) the following true:

Driver Package Installer script --> x86 build: OK! x64 build: FAIL!
Driver Integration script--> x86 build: OK! x64 build: OK!

Best regards,

Aeolis

Re: Driver Package Installer strange behavior under x64 builds
« Reply #8 on: October 12, 2012, 07:27:19 PM »

was_JFX

  • Code Baker
  • Grand Chef
  • *****
  • Date Registered: Dec 2010
  • Posts: 1074
So, there is no fix for the issue? If I want to install my graphic card driver on x64 builds it must be done by the Driver Integration script, isn't it?
Yes, it seems that this driver is just to big.

One solution could be to trim down the driver, but i have not done this for years with nvidia drivers.

Replacing NvCplSetupInt.exe with a 0 byte file would already help a lot, i guess.

 :cheers:

Re: Driver Package Installer strange behavior under x64 builds
« Reply #9 on: October 12, 2012, 08:13:52 PM »

Aeolis

  • Chef
  • ***
  • Location: Rio de Janeiro, Brazil
  • Date Registered: Oct 2012
  • Posts: 134
Hello folks,

Thank you again JFX! I've created a dummy (0 bytes) "NvCplSetupInt.exe" file and replaced the real one. It helped a lot, now it works. May I assume that I can do the same for my x86 builds, just for the sake of saving disk space?

Thank you again JFX :thumbsup:.

Best regards,

Aeolis

P.S.: Is there a way to trim it down even more (just curious about)?
« Last Edit: October 12, 2012, 08:16:10 PM by Aeolis »

Re: Driver Package Installer strange behavior under x64 builds
« Reply #10 on: October 12, 2012, 09:34:38 PM »

Aeolis

  • Chef
  • ***
  • Location: Rio de Janeiro, Brazil
  • Date Registered: Oct 2012
  • Posts: 134
Hello folks,

Although my problem with my drivers is ok, during all this debugging period I have noticed a strange situation after my system finishes installing my drivers. After it finishes my screen blinks and my monitor and graphic card get detected as usual, but after a few seconds my usb optical mouse gets disconnected (its red light turn off). The only way to prevent it is to, when it first turns off, start moving it as crazy then it gets on again (its red light turns on) and everything goes back as normal. If I forget to move it as mentioned it gets "forgotten" by the system. Even unplugging and plugging it back again doesn't help. I have already tried to re-detect hardware after unplugging and plugging back and it doesn't help neither.

Has anybody experienced it ever?

Best regards,

Aeolis

P.S.: My motherboard has only on PS/2 port which is connected to my PS/2 keyboard.
« Last Edit: October 12, 2012, 09:36:36 PM by Aeolis »

Re: Driver Package Installer strange behavior under x64 builds
« Reply #11 on: October 13, 2012, 03:09:23 PM »

was_JFX

  • Code Baker
  • Grand Chef
  • *****
  • Date Registered: Dec 2010
  • Posts: 1074
May I assume that I can do the same for my x86 builds, just for the sake of saving disk space?
Yes, same goes for x86.

P.S.: Is there a way to trim it down even more (just curious about)?
Properly, at least OpenGl and Cuda stuff are not needed in a WinPE.

About PS2 issue, if have no idea what could cause that.

 :cheers:

Re: Driver Package Installer strange behavior under x64 builds
« Reply #12 on: October 13, 2012, 04:19:58 PM »

Aeolis

  • Chef
  • ***
  • Location: Rio de Janeiro, Brazil
  • Date Registered: Oct 2012
  • Posts: 134
Hello folks,

Thank you JFX! Regarding the PS/2 problem I'll wait to see if someone else may have experience with that strange behavior.

Best regards,

Aeolis

Re: Driver Package Installer strange behavior under x64 builds
« Reply #13 on: October 16, 2012, 12:15:46 AM »

Galapo

  • Gena Baker
  • Grand Chef
  • *****
  • Location: Australia
  • Date Registered: Sep 2010
  • Posts: 2207
Regarding the PS/2 problem I'll wait to see if someone else may have experience with that strange behavior.

That's a weird problem with the mouse. I haven't experienced that before.

regards,
Galapo.

Re: Driver Package Installer strange behavior under x64 builds
« Reply #14 on: October 16, 2012, 05:05:20 AM »

Lancelot

  • Gena Baker
  • Grand Chef
  • *****
  • Date Registered: Sep 2010
  • Posts: 10350
Quite out of topic, here is another weird hardware problem I faced just yesterday,

Increasing resolution to 1280x1024x32 , with 75hz , on a lcd monitor, cause frequent reboots,
reported to me after some hours I left  :cool:
and be sure it is not easy to catch that on phone  :tongue:
Lowering to 60hz solved  :thumbsup:
Suspect GPU or PowerSupply  :wink:
( Since gpu and monitor nicely support this resolutions, maybe gpu fan (hopefully will be tested after some months), maybe powersupply (I hate on board powersupplies))
I can not physically check hardware deeply anymore ....

I hate hardware problems....

Well it is not related with Aeolis problem, but who knows above mini info may help you one day  :wink:  :great:
I remember I had moved mouse at boot (as decribed by Aeolis) in order not to loose it  :wink:, but many years ago, I can not remember conditions....

:ymca:












Edit: Further of current post is only a ChangeLog template for next package....
http://theoven.org/index.php?topic=2594.msg36245#msg36245


black      red      yellow      pink      green      orange      purple      blue
beige      brown      teal      navy      maroon      limegreen      white


INFO from slore Reply 135 http://theoven.org/index.php?topic=2390.msg32885#msg32885
Quote
Public tests is a good social experience for the developers to see behaviors of end users and to create out of the box working stable solutions.

For 19H1,20H1 already got feedback than RS5 tested.

* StartMenu reboot button will block.

StartIsBack needs to update to 2.8.4

* [known]Dism.exe can't work(Russian friend's PE is same).
needs set workgroup.

startnet.exe token 14 seconds, PECMD call is fine.
without PECMD, In startnet.cmd I try to use ChrisR's SetWG.exe.
it is OK, but it check lanmanstation service which is not necessary, I will feedback later.

* Services.msc got error(explorer.exe).

iframe.dll(12MB) -> mshtml.dll(22MB) -> Chakra.dll(7 MB) => needs JScript/HTA.
(I got solution now)

* devmgmt.msc can't work

wbem\WMI*.dll is required.


I will not update the WimBuilder2.part1,2.rar frequently ....

please use git pull or download from github if you got the same issues.

slore Reply 2 http://theoven.org/index.php?topic=2795.msg32886#msg32886
Quote
It Checks if the LanmanWorkstation service is Running and Start it Otherwise

some PE don't have wkssvc.dll, so the LanmanWorkstation service can't be started.

I tested startnet.exe(token long time) or CALL $Netapi32.dll,NetJoinDomain,,WORKGROUP,,,,1, then Dism.exe can mount wim without error.

In some case, there is no PECMD, so, will you leave an option --- do not check the service?


INFO from slore Reply 110 http://theoven.org/index.php?topic=2390.msg32804#msg32804
compmgmt.msc needs jscript  (custom msc with devmgmt,diskmgmt,services is OK)
diskmgmt.msc needs WMI      (diskpart.exe, PartitionGuru is OK)
bitlocker needs WMI
shortcut's opencontainingfolder menu needs ieframe.dll(12MB) (WinXShell.exe has wxsStub.dll(100kb))
URL assocation(http/ms-settings) needs ieframe.dll [ms-settings:taskbar]  (modify registy + binmay)

INFO from slore
If you want to use Dism in WinPE, set WORKGROUP before using dism command.
Code: [Select]
startnet.exe -wg WORKGROU
+
slore reply 1 http://theoven.org/index.php?topic=2795.msg32823#msg32823
Someone report that startnet.exe maybe fail, I thought to create a <3kB C program.
But they give a line to use PECMD.exe.
startnet.exe -wg WORKGROUP || pecmd.exe CALL Netapi32.dll,NetJoinDomain,,WORKGROUP,,,,1

next package after Win10PE_SE_2019-03-16:
TODO: FireFox Sounds http://theoven.org/index.php?topic=2781.0
TODO: Lancelot: PECMD options http://theoven.org/index.php?topic=2777
TODO: Bob.Omb: Logon Admin options http://theoven.org/index.php?topic=2778  (enable Logon Admin plugin but login as System )
TODO: Bob.Omb: Logon Admin -> missed Slide to Shutdown picture (missed copy .jpg file I guess ;) )
TODO: Lancelot: Hotkey options for pecmd http://theoven.org/index.php?topic=2777.0
TODO: Lancelot: JFX -> ADK4 (Windows 8.0) have the last tools that work on XP. ==> Write Instruction including hostos support ...
+ Instruction -> none Media Creation source. + no AV

*
Next Release preparations:
+
Lancelot: DXCore.dll joinutil.dll netprovfw.dll umpdc.dll -> let me quick boot to cmd.
So far I see slore add
umpdc.dll to wow64 and IE
DXCore.dll to IE
joinutil.dll -> switch to admin with a note "in winre.wim"
and nothing about netprovfw.dll ---> well I can not get cmd shell screen without netprovfw.dll ....
JFX:
I agree "1 - Copy Files" is the right place for these 4 files
Also umpdc.dll should be added to WOW64 plugin.
Joinutil.dll and netprovfw.dll looks more like a silly bug made by MS, so maybe future version will not need them...
+

Slore:


commit 2673178f Support Windows 10 19H1 source
/00-Configures/Build/WoW64_Basic/submain.bat
Quote
@windows\SysWOW64\
C_*.NLS,KBD*.dll

+ver > 18300
umpdc.dll
+ver*

commit fdcec843 fix issue that 19H1,20H1 can't switch to Administrator account.(yamingw)
/00-Configures/System/Admin/SwitchToAdmin.bat
Quote
+ver > 17700
Windows.UI.Xaml.Controls.dll,Windows.ApplicationModel.dll

+ver > 18300
wuceffects.dll
+ver*


commit 13bc0470 update 19h1 support
/00-Configures/System/Admin/SwitchToAdmin.bat
Quote
rem add all as default
set VER_CNAME=.*.
if %VER[3]% GTR 17000 set VER_CNAME=.rs4.
if %VER[3]% GTR 17700 set VER_CNAME=.rs5.
if %VER[3]% GTR 18300 set VER_CNAME=.19h1.

@\Windows\System32\

; 1709 uses Xaml.Resources.dll,1803 uses Xaml.Resources.rs4.dll and 1809 uses Xaml.Resources.rs5.dll, ...
; Keep both for compatibility with both versions
;Windows.UI.Xaml.Resources.dll,Windows.UI.Xaml.Resources.*.dll

Windows.UI.Xaml.Resources%VER_CNAME%dll

/01-Components/IME/Ime_Common.bat

Quote
+ver > 18300
umpdc.dll
clbcatq.dll,dusmapi.dll
netprofm.dll,npmproxy.dll
Windows.Networking.HostName.dll
TextInputMethodFormatter.dll,WordBreakers.dll
+ver*


:Ime_Reg
if %VER[3]% GTR 18300 (
  call RegCopy %1\Microsoft\FuzzyDS
)

Chris:
I saw that WOW6432Node\Microsoft\FuzzyDS is not included in install.wim but are there once installed.
To get it at build time, I did it like that:
Code: [Select]
ShellExecute,Hide,cmd.exe,"/C Reg Copy #$qHKLM\Tmp_Software\Microsoft\FuzzyDS#$q #$qHKLM\Tmp_Software\WOW6432Node\Microsoft\FuzzyDS#$q /S /F"
Slore:
If there is no FuzzyDS in WOW6432Node, then needn't copy them from Tmp_Software\Microsoft.
I tested IME in 32 bit APPs, it works.

By the way,
For the latest 19H1,20H1 version, it needs more registy items.
IME works with full SOFTWARE only now(WimBuilder v2019.03.31).
(Edited: Confirmed Software\Microsoft\Input is required)

And the candidate words bar is changed to be MetroApp,
so you can't select the words, needs type a phrase for inputing words you want,
otherwise the first candidate word will be inputted.

I have to seperate the IME indicator, and add 3rd part Input Method software.

/02-Apps/Browsers/IE/main.bat
Quote
+ver > 18300
DXCore.dll
*ver


commit 24fd326a fix issue that 19H1,20H1 can't use IME.(yamingw)
 /01-Components/IME/Ime_Common.bat
Quote
TextInputMethodFormatter.dll,WordBreakers.dll
Language*.dll
Windows.UI.Core.TextInput.dll

+ver*


commit 1446ea0e update New Browse Dialog for the latest 19H1,20H1(JFX)
/01-Components/00-Shell/Explorer/submain.bat
Quote
+ver <= 17700 or (ver > 18334 and ver < 18800) or ver > 18836
shellstyle.dll
en-US\shellstyle.dll.mui
; remove ver check (add with any ver)
+ver*


+
cretino
SystemResources\Windows.UI.Logon folder gets Switch to Admin work

+
slore
Wlansvc not start solution:
commit 982e7c22 remove WcmSvc from Wlansvc service's DependOnService
wcmsvc which does not start and so wlansvc
Chrisr:
However, I think I found, The netprofm service, not written as dependency, seems necessary.
I need more testing but it looks good with only the netprofm registry services even disabled, Start=4 and without files dependencies.
RegCopyKey,HKLM,Tmp_System\ControlSet001\Services\netprofm
RegWrite,HKLM,0x4,Tmp_System\ControlSet001\Services\netprofm,Start,4
+
it looks good with the netprofm service even disabled
+
With Network additions, I will add the netprofm service with start=4 disabled
But yes it's worth a try with the full software hive and without network additions
and to remove wcmsvc as a wlansvc dependency.
It is fine if it works like that.
Without the need for "network additions" dependency for DotNEt and Admin (they use the full Software)

*
Doberman:
New menu requires AppRepository
StateRepository-Deployment.srd
StateRepository-Deployment.srd-shm
StateRepository-Deployment.srd-wal
StateRepository-Machine.srd
StateRepository-Machine.srd-shm
StateRepository-Machine.srd-wal
Slore:
After 10.0.10240, no need AppRepository for New Menu.
And another point that make New Menu works, why put them in WOW64 plugin?

*
Some ChrisR Notes for mui mun files

; cdosys.dll.mui   (Orphan Resources Files) - cdosys.dll does not exit in winre.wim but it exists in install.wim
; clfs.sys.mui   (Orphan Resources Files) - clfs.sys is in drivers folder
; dxgkrnl.sys.mui   (Orphan Resources Files) - dxgkrnl.sys is in drivers folder
; dxgmms2.sys.mui   (Orphan Resources Files) - dxgmms2.sys is in drivers folder
; mpsdrv.sys.mui   (Orphan Resources Files) - mpsdrv.sys is in drivers folder
; psmodulediscoveryprovider.mfl   (Orphan Resources Files) - same in winre.wim or install.wim
; Windows.CloudStore.dll.mui   (Orphan Resources Files) - it is done intentionally, the mui is required for Pintool but not the dll
; wcncsvc.dll.mui   (Orphan Resources Files) - wcncsvc.dll does not exit in SysWOW64\en-US\ same in winre.wim or install.wim

There is also: \Windows\SystemResources\Taskmgr.exe.mun  added bur it is not necessary with the old boot.wim task manager

exclude anomalies for drivers, if finished by ".sys.mui"
And When time allows, I'll add maybe an ini file with an exclusion list

*************************************


Updated Win10PE_SE_2019-XX-XX - Package

Thanks to all who feedback so far.  :xmas-beer:

Changelog:

New \TweaksY\Theme\Theme - MS Windows Media Player - WIEBENOR Plugin - Thanks to WIEBENOR

* \Build\Themes Plugin - updated Thanks to JFX

* \Drivers\DrvInstPatch Plugin - updated Thanks to JFX

* \Apps\File Tasks\Total Commander Plugin updated v9.22a

* \Apps\HD Tasks\Active@ Partition Manager 6 Plugin fixed Thanks to cretino and thanks to jmsallo for reporting.

* \Apps\Network\Mozilla FireFox ESR (P) Plugin updated - Thanks to Nikky for Custom Profile option.  :cheers:

* \Apps\Security\Passwords\Windows Login Unlocker Plugin updated - Thanks to CryptoNick (Joker-2003) for all updates.  :cheers:

* \Apps\System Tools\Explorer Addons\ExeProperties (ExtraBit) Plugin - updated to v1.4.1.0

* \Apps\System Tools\Explorer Addons\HashTab v5 v6 (olegpov) Plugin - updated to v6.0.0.4

* \Apps\Network\Firewall\Simplewall Plugin updated v2.4.6.0

* \Downloads\Download Plugins X Plugins Improved - Lancelot Now Provide Full DownloadX List
--> using feature Downloading Plugins with a CodeBox:

Slovak Translation Added - Thanks to Brahma


Reminder:
Gena, Win7PE SE, Win8PE SE, Win8.1SE also updated with related changes.

Win10PE SE Downloads Page

Enjoy!  :cheers:
« Last Edit: March 07, 2020, 06:35:08 PM by Lancelot »

 

Powered by EzPortal