MRP 114 is now at RC1 Regarding the changes (may of already mentioned them in previous post(s) but here in a little more detail): 1. This is for Windows 10 Only. From v114 you can have a image file called LockScreen.jpg in the brand folder of your choice that is an image different to the Wallpaper ('log-on' screen), if that new file is detected then MRP will use that for the lock screen image. The 'Log-on' screen will still be the Wallpaper.jpg as normal. Image dimensions/resolution usually are 1920 x 1200, but i think anything lower or higher is auto converted to what the OS requires. If the file size is greater than 1.9MB then a message line will appear in the project.log file, this is for info only, as if you go above 2MB it can take a few seconds for the OS to convert/trans-code the file for it to be displayed for the first time. This is OS controlled and nothing to do with the project. 2. New Win 10 Only option: Remove that over the top blurred 'log-on' background image display for 19H1+. A revert script will be available if you wish to change it back to the blurry vision again. This is a working option at the moment but m$ may remove that method to un-blur the image in the future. 3. Fixed a weird glitch with some Editions, (such as Enterprise), that if using the default OS key, (ie no PID.txt or key entered during setup), it would show the KMS standard date/time information by mistake. Now MRP 114+ will just inform you that the key used, be it the default or 'other' key, is invalid and not usable to activate. 4. MRPConfigCreator/Editor has been updated to v19.0 to include the new W10 option in #2 above. Also some new tool tip data on various options where needed. ETA for v114 ~~ before the end of the month*. Query Tool v95.0 ~~ Within next 3 to 4 days*. Other additions/changes may appear by the time the project(s) are released. * Times shown are approximate.
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?