Ok, I'm slowly narrowing it down.. When it stops at the v4.0.xxxxxx .net info, is there any error message? also if you press a key and it continues it then aborts at the compiling output part. I am running the script in stages on my test to see what is being called/used as it goes along. I think the first stop after .net is caused by a Wmic check for the MSDM key (method 1). that call might not be present on win 7... if that so then that easy to fix - ignore if not windows 8+.
hmm that is a very old version of the QT.... but its picking out the MSDM area with FF's in which may be the cause! ???
Well i think the cause is a BIOS issue and not QT/MRP in the case of the motherboard your using. Im just going to grab a copy of the latest bios for that board and look though it if that has the invalid MSDM area then this is the cause for the project files to abort...
Well your board is rev.2.0 (latest bios: 58aud3r.fh) Revision 1.0 does not have the dummy MSDM table. The latest bios has a dummy MSDM table within. This is causing the QT and MRP to fail.
As you can see in latest Results.txt I've got FH5 (beta?) bios but most likely even in FH (latest official) MSDM is dummy.
Ok please open a command prompt window as administrator. Copy/Paste this into the window and let me know the results... Code: wmic path softwarelicensingservice get OA3xOriginalProductkey /value Is should come back as either empty or OA3xOriginalProductKey= with nothing within, or even an error message.
yes i looked at fh (latest) and it does have the dummy table. If the results from the OA3 test come back with an error at least i may be able to parse the results in the QT/MRP so that if the data is invalid then to ignore it.
I do a two method way to obtain the MSDM key from the table, but because the table is present (with dummy info) the Wmic and the Generic_2.exe (Alphawave's) file i use to obtain the info the data returned may need to be parsed for valid key length.
a-ha! ok i can fix that error... that is the first fix that is easy. let me edit QT and give you another test one to try, it should then go past that error. The next may be a bit more complicated to fix but one way or another will get around it!
@mad_max Sent you a PM/Convo with a link for the test QT Hopefully this will allow the QT to complete properly.
Link removed. If any one with win7 would like to test this too. Will delete link once results are in. If this fixes this issue then i will release the new fixed version.
MRPQT v25.1-Test has issue that v25.0 does not... #11 MSDM Brand Name - (Missing) Both versions report properly otherwise... -------------------- - Scanned DMI/BIOS - -------------------- #01 CSProduct Name - G750JM #09 SLIC Version - 2.1 {Possible Loader} #02 CSModel Name - G750JM #10 Product Key - Not Shown On Saved Report. #03 CSBaseboard Prod - G750JM #11 MSDM Key - Not Shown On Saved Report. #04 CSProduct Vendor - ASUSTeK COMPUTER INC. #11 MSDM Edition - Win 8.1 Core #05 CSManufacturer - ASUSTeK COMPUTER INC. #11 MSDM Brand Name - #06 Baseboard MFR - ASUSTeK COMPUTER INC. #12 BIOS/Boot Mode - Legacy/MBR #07 Serial/Service Tag - Not Shown On Saved Report. #13 Certificate - Present #08 BIOS or SLIC ID - _ASUS_ #14 License Status - Licensed {OEM_SLP Channel}
in the test if win 7 is detected ive just bypassed the MSDM bits temporary hence why the name is not present. Once the issue with mad_max's crashing problem is sorted i can then work on a way to fix the issue of a dummy msdm table. I will create a VM with the same MSDM table present within the Gigabyte X58's bios to create a test environment. I do have a method in my madness lol.
Well.. almost perfect I don't need to press a key but when I run it for the first time window just close right after "tiding up" results. Second run was more successful:
Well sadly i cant fix the problem as the error is within Generic_2.exe Will need to talk with Alphawaves as the error generated is something i had expected but the exe does not handle it in this case for a dummy MSDM table! The error returned is: Non-negative number required. Parameter name: count Then it waits for a keypress which is what mad_max was saying. Then of course QT fails at the end when compiling the data because of the error that throws out the section that shows the information.
The error is caused by the loads of FF's within the dummy MSDM, because FFFFFFFFFFFFF.... is not a number that is used within a key as such , mainly because there is no - between them its all one block. Generic is sees it as one huge number which due to how the interpreter sees it goes into a negative number! ie overloads the maths.
Just trying to find a work around. may have to put a message after the .net/pshell stuff is tested to press a key if QT seems stuck. (this is where Generic gives that error and waits).