The new disable Blurred log-on background option is already working Other news: QT 95.0 is a bit delayed as sorting out some new info - if all goes well... It may not be 100% accurate all the time as so many factors to consider as some names/data are very close to others. Will give more info later...
As posted before about the QT/MRP more info... I will just leave this here... Spoiler: A bit more info... Code: Code Name : Skylake Socket Type : Socket 1151 Lithography {Die Size} : 14 nm Thermal Design Power {TDP} : 65 W Released : July 2015 Still under testing, the database(s) are not fully complete and some CPU's may not show this new info. But they will be added when data is available on the next release of the QT/MRP. AMD's Ryzen 9 ? {latest one} and some i9 Intel's may not show the new info as i not have all the data for those yet. There is over 1,800 total CPU entries in the combined AMD/Intel database(s) at present - which hopefully should cover the majority of current, (pre 2019), processors about, have added as many late 2018 and early/middle 2019 ones as i could. The 'Socket Type' may state things like G2, G3 etc --> this is what the actual, {ZIF/other}, socket is called by the CPU maker and not a spelling mistake. Cannot guarantee if two very closely named CPU's give the incorrect data. Not really a fault of the project but a oversight on the CPU maker for creating two with the same name! This is something i have been working on/off for the past few months and i not been able to use before as i had to work out a way to parse the CPU's info and then match the data in the, (now larger), database(s) to be in some understandable format! The routine doesn't use any 3rd party programs, it is all WMIC and batch commands.
Due to some inaccurate data returns i have decided to not include the extended cpu data (code name, TDP etc) as when a CPU name is very close to another i cannot get the routine to pick the exact wording required. So for now that will not be present in the project(s).
Hello, is this bug fixed? When I use MRP with an updated Windows 7 x64 installation find.exe runs indefinitely Thanks
MRP does not use find.exe , in a few areas it uses findstr.exe, only once before was it reported, (as you quoted), that it 'hung' the windows installation. In many tests with fully updated windows 7 (and others) no problems was found. If you are using any external tweaks etc such as a setupcomplete.cmd etc may be one of the commands within that is causing the problems?
I do not use anything else, I slipstreamer the updates for the OS is up to date. But no other scripts or tweak. In task manager i see find.exe ! I kill it three times and OOBE.cmd continue...
I am guessing that the updates are integrated into the install.wim before OS installation? Such as using the Simplix pack? I am unsure why it is failing as I know @Enthousiast uses the Simplix pack to update his Win 7 iso's and then tests with the project for me, not had any problems as such before, (only the once which was quoted earlier). I know for sure that the 'Find.exe' command is not used within the early stage of the project as it has limitations which the newer 'findStr.exe' command does not. The 'findstr.exe' command is used in the 'Add-On Manager' - which is run after you have entered the username etc so it is way past the initial setup stages. When i get time i will take a closer look into the early stages of MRP even decompile.exe itself. It seems it is a rare event which makes it very hard to pinpoint.