MRP 96 at RC2 stage and two other new Win10 only options added. More details later once testing has been done to make sure they work.
RC2 Test complete... New Options are working and in effect. Spoiler: Details Win10 Kernels Only: 1) Show Command Prompt instead of Powershell on the Win-X Menu. Exactly as it says. 2) Disable EV Cert/Sha256 (Advanced Option - Experimental). ---> This attempts to avoid the driver signing enforcement for EV cert / SHA256 Microsoft Windows signed drivers which is further enforced via Secure Boot. Basically this would prevent you from installing non M$ new 'sha256 type signed' drivers but on a more stricter level than the BCDEdit version. Hopefully this allows you to use non Sha 256 signed drivers. Note this 'tweak' does not use BCDEdit just a obscure registry entry. It is experimental -- it works on UBR 1 (baseline 'RTM') however it could be bypassed by a later Cumulative Update as m$ are getting rather aggressive. General ALL OS's: 3) Disable auto restart if a system failure {BSOD} occurs. Allows you to see the STOP error and not just instantly restart the PC then have to go searching the Event log why the OS crashed. The Config Creator v5.3 has been updated with the new Options. Hopefully MRP96 will be ready by the end of the week.
Hello When using this OEM project, which file is responsible for installing the different versions if Windows 10? Windows 10 Core Windows 10 Home Windows 10 Pro Windows 10 Education Thank You...
Yep your right. This is one of the rare cases where the conflict routine gets confused. It has a choice between Microsoft (which could be the Surface) or EMachines, as Virtual could also be a VirtualBOX VM, but it has ignored that one because it determined that in another check that it was not VBOX. It chose 'EMachines' as it 'looked' like a match. The routine is complex and this is one of those times it failed. One of the reasons is Microsoft changes the naming of Hyper-V which causes a bit of a screw up! When you used MRP 95, did it also install the EMachines theme? I will take another look into the routine as i may be able to 'tweak' it to use the HyperV theme which technically it should of 'used'. If you still have the Project.log from the MRP95.0 installation which could be posted that would be a help as i can cross reference areas to see where things went wrong. Thanks for bringing it to my attention. I thought i had sorted that area out as i used to use Hyper-V but it not like other VM software installed so gave up using it due to the hassle it cause me.
Code: #01 CSProduct Name - INVALID #02 CSModel Name - INVALID #09 SLIC Information - SLIC Table Corrupt or Invalid Data As can be seen Lenovo has some strange information! The Invalid bit is because the information in the DMI has odd non standard characters in so to prevent errors it says invalid. The SLIC table is also messed up, it may be a dummy type with random information or like HP and a few other makers the SLIC is invalidated when a OS other than Vista/7 is installed. In this case it managed to find Lenovo via one of the other entries.
QT64 will have a hopefully better detection of HyperV VM's, it is a bit more complex than normal VM software such as VBox, VMWare etc. I am guessing because HyperV is used on Servers that it has to be as close to a real PC as possible which can be awkward to detect via scripting. Humans can see the differences but a PC has to be told what to look for - that is the tricky part. It could by mistake pick Microsoft Surface. In the case of the EMachines being used as the name because the word Machine was within the EMachines name the QT (and possibly the MRP) would use that as the closest match. The new secondary routine seems to be a bit more clever. It has on my test QT, (with same sort of DMI/Bios data as a HyperV VM), found the HyperV data correctly. Code: SCANNED ======= #01 CSPRODUCT NAME - Virtual Machine #02 COMPUTERSYSTEM MODEL - Virtual Machine #03 BASEBOARD PRODUCT - Virtual Machine #04 CSPRODUCT VENDOR - Microsoft Corporation #05 COMPUTERSYSTEM MFR - Microsoft Corporation #06 BASEBOARD MFR - Microsoft Corporation #07 SERIAL/SERV TAG - Debug Test #08 BIOS or SLIC ID - VRTUAL - 1 SUMMARY ======= THEME - HyperV [id:-'HV'] ACTIVATION - Un-Listed VALID [OEM OS] - Un-Listed The code for the MRP side is a little bit more complex, so it may say the conflict resolution has kicked in with EMachines but the secondary routine should kick in to actually get the theme correct. It's all theory as i not used a HyperV VM to install a OS for a long time. Because of this 'glitch' it may take a bit longer for MRP 96 to be ready for release as quite a bit of reworking needs to be done.
Thanks for the mrp log. Yep as i thought it also used Emachines as the theme. Hopefully it will be sorted for the next release. But first i will get QT64.0 finished to see if it will fix this strange glitch.