Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


wimb

Developer
  • Content Count

    763
  • Donations

    $0.00 
  • Joined

  • Last visited

Everything posted by wimb

  1. Thanks for version 4.0 RC1 which solves the Edit option for unattend.xml Did some testing with Apply of latest Win10 install.wim from Microsoft followed by wimlib Capture and then Apply in WimBoot mode using wimgapi. It seems the RC1 version corresponds to the 4.0 Beta 8 version and everything is working as expected and OK as long as the internal Windows\System32\WimBootCompress.ini is not modified.
  2. wimb

    System_Info

    System_Info - Updated to version 4.1 - Added 2 extra buttons to make Folder List and FileList from Selected Path and using Dir Command with Unicode support - Allows to keep multiple processes alive and visible System_Info is also available at Reboot.pro Forum
  3. For Unattend the option right-click to open that file in notepad does NOT work anymore in 4.0 Beta 6/7/8
  4. It is file bootmgr and file Boot\BCD that definitely need to be decompressed for booting VHD with grub4dos from RAMDISK in WimBoot mode. Decompressing the whole folder \Boot and \EFI is not needed and would take more free space from VHD and increase the time to load VHD into RAM. Booting with VHD in WimBoot mode from USB on various hardware can be improved when drivers are real files instead of WOF pointers. It is used to make a Portable Windows 10 Operating System in VHD booting in WimBoot Mode and located on Portable SSD connected via USB. But since Apply with wimgapi in WinNTSetup gives trouble in decompression of Windows 10 drivers, I think it is better NOT to add such option in WinNTSetup. We can use Apply with wimlib using WIM file Captured with wimlib and modified Windows\System32\WimBootCompress.ini if we want to have decompressed drivers in Windows 10 VHD booting in WimBoot mode.
  5. Yes you are right. I went back to the original Windows\System32\WimBootCompress.ini of Microsoft with simple PrePopulateList that does not contain the line \Windows\System32\drivers\*.sys Then I did a Capture using WinNTSetup with wimlib and used the WIM file for Apply using wimgapi. As you say indeed in that case there is no driver problem with wimgapi anymore. It means however that we cannot PrePopulate with drivers in this way, which can be useful for booting VHD from USB in WimBoot mode on various hardware. Also files \Boot\BCD and bootmgr inside the VHD are WOF pointers, so that booting with grub4dos from RAMDISK using SVBus driver does NOT work anymore. For some cases it is desired to use modified WimBootCompress.ini and for that case wimgapi cannot be used in WinNTSetup, but wimlib will work fine. It is also a bit confusing that your Tools\WimBootCompress.ini file that has the line \Windows\System32\drivers\*.sys is not used at all in case of Windows 10. Only the WIM Internal Windows\System32\WimBootCompress.ini is used for Apply of Windows 10 with WinNTSetup.
  6. Very Interesting In Beta 8 wimgapi results mostly in WIM backed driver files (WOF pointers) allthough the PrePopulate list instructs to make real files. In Beta 7 your code is doing better since then most driver files are indeed real files instead of WOF pointers. In both cases for some drivers the process fails and the error occurs when in the WIM file there is no iNode for these files. As conclusion we can say that wimgapi cannot be used in wimboot mode and wimlib is doing fine for this purpose. It would be better when for Capture the WimBootCompress.ini file in the WIM file is replaced by your Tools\WimBootCompress.ini file. That is what wimlib Capture is doing when --wimboot --config option is used. In this way the user has easy influence on what is occurring for Apply when the Internal Windows\System32\WimBootCompress.ini is used. As it is now the user can modify Tools\WimBootCompress.ini but these changes are not used during Apply.
  7. Thanks for the Info. How come that in Beta 8 for Apply wimgapi + WimBoot most drivers become WOF pointers and in Beta 7 are real files, whereas both Internal and External WimBootCompress.ini files contain in the PrePopulateList a line \Windows\System32\drivers\*.sys ? I assume that in Beta8 you overruled WimBootCompress.ini for drivers\*.* to be WOF pointers, but I think it is better to have that action not hardcoded. It is nice as a test since it has helped me to see where wimgapi is failing since there is a bunch of files not having the WOF pointer. For Beta 8 the 3 troublesome drivers btfilter.sys and nvhda64v.sys and TeeDriverW8x64.sys are clearly visible in 7-zip (sorted for WOF) as being not a WOF pointer.
  8. In Beta 8 for Apply wimgapi + WimBoot mode then most drivers are WOF pointers except for the troublesome drivers which files have normal size, but filled with byte zero. The bug is that somehow wimgapi is treating some drivers differently ..... It seems to me that only the Internal Windows\System32\WimBootCompress.ini is used. In what case and how is the file Tools\WimBootCompress.ini by WinNTSetup supposed to be used ? Capture with wimlib using --wimboot and --config replaces the internal WimBootCompress.ini file with the one used for Capture (property of wimlib) Such replacement of the internal WimBootCompress.ini does not seem to occur in WinNTSetup.
  9. Thanks for Beta 8 Driver Problem with wimgapi + WimBoot still the same, e.g. btfilter.sys file has normal size but composed of only byte zero
  10. The internal WimBootCompress.ini of the WIM file Applied with WinNTSetup is equal to my WimBootCompress.ini due to earlier Capture with wimlib in VHD_WIMBOOT Capture with wimlib using --wimboot and --config replaces the internal WimBootCompress.ini file with the one used for Capture (property of wimlib) WimBootCompress.ini
  11. When Tools\WimBootCompress.ini was removed then the After Apply wimgapi + WimBoot mode the driver files are present as file and not as pointer. So I thought that may be the {PrePopulateList] of the internal WimBootCompress.ini was used. Install of WofTab does not make any change on Properties of driver files. The drivers in the VHD are not compressed and I copied also these drivers to internal SSD for investigation of Properties.
  12. Inside the Captured WIM file there is another Windows\System32\WimBootCompress.ini that is probably used when Tools\WimBootCompress.ini is removed. What is WofTab doing ?
  13. After Apply with wimgapi + WimBoot mode then the three problem drivers have in Properties missing Digital Signature tab After wimgapi Replacing simply the three drivers btfilter.sys and nvhda64v.sys and TeeDriverW8x64.sys by the drivers found in the wimlib installation solves the problem. That means the problem is entirely located in the three drivers having missing Digital Signature tab after Apply wimgapi + WimBoot mode Then I investigated the drivers in TinyHexer. To my surprise the driver file after Apply of wimgapi + WimBoot mode is completely filled with byte 00 [PrepopulateList] files WOF Uncompression Failure resulting in zeroed driver file ? After Apply wimgapi + WimBoot Mode After Apply wimlib + WimBoot Mode
  14. Thanks for your help and suggestion to use x64 wimgapi.dll version 10.0.15063.0 (from Windows 10 version 1703) supporting SHA1 and SHA2 GetWaikTools old Versions has GetWaikTools_v17.04 is giving x64 wimgapi.dll version 10.0.15063.0 I tried that wimgapi version in WimBoot mode, but the three drivers still have exclamation mark due to seemingly Unsigned driver. @jaclaz Indeed the wimgapi tool might be too "secure" or it might be in the code that JFX is using. In any case there must be somewhere a difference in the installation as compared to using wimlib. Until now the installation for Apply in WimBoot mode looks quite the same for wimgapi and wimlib and I haven't found the location giving the driver trouble .....
  15. After Apply wimgapi + WimBoot Mode I tried to replace the complete registry with a backup (12 files) where drivers were working OK. It turns out that this replacement of the registry did not solve the problem. The three drivers as before were having exclamation mark due to seemingly Unsigned drivers, but as we know now it is only the Certificate that is not taken properly into account. Anyway I thought it is interesting to mention that a replacement of the registry cannot solve the issue. Where is the problem located ? Somewhere in ProgramData ? Some WOF Compressed files ? I checked in the VHD by using 7-zip that the drivers\*.sys files and Catroot folder are not WOF Compressed. Could it be that some other essential files need to be Uncompressed ? Anyway when WimBoot mode is not used in wimgapi Or when wimlib + WimBoot is used then all drivers are working OK.
  16. Thanks for giving info about where and how to find driver certificate info. The three drivers giving problem have their signature inside the sys file. The drivers appear as Unsigned, but after Update driver then the same driver file appears as Signed. So it seems to me that the only problem is that the Certificate is not recognised ....
  17. Removed WimBootCompress.ini and did Apply wimgapi + WimBoot Mode. Result is that system boots ok, but as before there are 3 drivers with exclamation mark due to apparently missing certificate. Do you know where the driver certificates are located ?
  18. Testing now on my own computer ASUS-Z170 In case of wimgapi for Apply in WimBoot mode then some drivers seem to be unsigned and seem to have missing certificate. Updating the driver using the already present driver files resolves the problem. The Certificate is now visible. Where are the Certificates located and are they may be wof compressed for the drivers having problem ? ==
  19. Thanks for your help. I will use 7-zip to investigate the vhd file to see whether the non working driver files are excluded for wof compression. Otherwise the best advice is to use wimlib for Apply in WimBoot mode, since then all drivers are working OK
  20. The problem only occurs when wimgapi is used for Apply in WimBoot mode. In that case some non-Microsoft drivers get an exclamation mark, whereas they were properly installed in the captured installation. So it means that when the WimBoot mode is unchecked then wimgapi Apply also properly installs the drivers. It is completely dependent on using WimBoot I think it is a general problem, since I observed similar behaviour on other hardware and other architecture. Apply wimgapi + WimBoot mode makes that some non-Microsoft drivers fail to work (have exclamation) mark May be something with files present as pointers instead of as real files ...
  21. I think it is how the [PrepopulateList] is applied in wimgapi WimBoot mode as compared to wimlib WimBoot mode. The [ExclusionList] determines the wimlib Capture, which is used for both Apply cases .... so that cannot be the source of the problem.
  22. Thanks for 4.0 Beta 7 version including BOOTICE and wimlib wimgapi Apply in WIMBOOT Mode of same WIM file as used before is giving the same problem as before. The 5 non-Microsoft drivers appear with exclamation mark and don't work .... The wimgapi Apply in WIMBOOT Mode has progress jumping from 26 % quickly to 100 % This was observed also in the previous version, but I thought it might be important to mention it here .... For wimlib Apply in WIMBOOT Mode then all drivers are working OK (no changes needed). Version 3.9.4 wimgapi Apply WimBoot Mode gives the same driver problem: 5 non-Microsoft drivers don't work.
  23. https://1drv.ms/u/s!AqA1-Hg3ltssgoIroves3EeeLlM7FQ?e=FFkbQS The shared file compression.zip contains: wimgapi_compression.txt wimlib_compression.txt All operations were carried out after booting with WIN10XPE from RAMDISK First wimgapi was used to Apply the wimlib Captured file W10x64_1905.wim to VHD mounted as drive D: followed by compact /s D:\*.* > C:\WimBoot\wimgapi_compression.txt After formatting drive D: then wimlib was used to Apply same wimlib Captured file W10x64_1905.wim to VHD mounted as drive D: followed by compact /s D:\*.* > C:\WimBoot\wimlib_compression.txt
  24. I am having an issue when using wimgapi for Apply in WimBoot mode using WIM files Captured with wimlib or wimgapi. The problem is that 5 non-Microsoft drivers get an exclamation mark that can be easily removed by Update of the drivers (already present in the installation). When using wimlib for Apply in WimBoot mode of the same WIM files Captured with wimlib or wimgapi then all drivers are installed correctly. In all cases I am using VHD + WimBoot mode. The wimgapi Apply problem does not occur when WimBoot mode is not used (mode unchecked). The wimgapi for Apply in WimBoot mode non-Microsoft driver problem occurs for both architectures x86 and x64 VX643-PC_System.txt
  25. The Capture [ExclusionList] section in Tools\WimScript.ini is much shorter than in WimBootCompress.ini given by Microsoft. What is the reason not to use a lot of entries given by Microsoft ? Certainly useful can be entries like \Windows\Logs\* \Windows\Prefetch\* \Windows\Temp\*
×
×
  • Create New...