It was my first thought as a corrupted slic will usually crash MRP, well it used to until i added in more checks and the log shows its OK. But it certainly memory related as that is where the log stops indicating that during identifying its type etc that caused the project to abort. Not much i can do to fix that as it could be a hardware issue.
That might be the issue why it did not activate using SLIC too, but now I am doing a memory test on memtest86 so I will see if there's anything wrong. If so then I will lower the voltage/not overclock my memory anymore...
it could just be a single byte or 'nibble' (part of a byte) that is out of whack. but it certainly indicating something along that line of investigation. On some genuine HP computers the ram side could crash MRP because of the way the memory array system was designed, i had to skip that ram check routine on those HP/Compaq systems. Never had Gigabyte fail before, it may just be a quirk of the P35 chipset used on that board. Sadly nothing i can do except skip the ram checks if gigabyte detected. But then that affect every gigabyte board too.
Fussy ram not exactly faulty can cause some very odd effects. Also if that type of ram is not in the ram compatibility list for that board may be the issue. So many ways tech can act out of character. Over clocking/volting may be the cause, who knows. It certainly ram related of some sort as it threw some exception error that was severe enough to crash out the WMIC memory checks taking MRP along with it!
Yeah. Well I did not see this kit on the QVL list for my motherboard. But it is possible that high clocking can cause instability as this memory wasn't made to operate at this high of a voltage in the first place. I will disable it and then try again...
Well is there maybe any and I mean ANY, way to disable that RAM checking (like show me how do I do it, by chance, but just maybe)
No as it within the MRP code , i would have to rewrite that section. As i am still working on the last bits of MRP 159 i could add in a option to ignore ram checks. As it is late here i wont be coding tonight, it will have to be tomorrow evening. Will see what i can do, as it could be useful if another system has that effect with ram.
Ohhh, okay then. Well you don't have to do it if you don't want to, I completely understand... and yeah it could fix it if someone has an issue with the RAM like I do too.
Yeah here it is late for me too. If you can add an option, it would be very useful. I will see what I can do with this memory aswell!
Just looked at mrp code quickly as i do skip ram checks also when a VM is detected as they can have issues. So i have just added in a variable check, which if set, within OOBE.cmd then MRP will skip all ram checks. Its a simple but hopefully effective way to just bypass ram checking, so you wont have ram capacity or type etc shown in the MRP's log. But that a small price to pay if it allows everything else to work. I wont add it to the creator this time round as i have already finalized that exe's code. I will send you a test version soon via pm and a oobe.cmd with the variable set in it ready so you just need to overwrite the decompile.exe and the oobe.cmd in your scripts folder.
@LuKaWin10 check PM. Link valid for 1 hour though. Extract files from archive, overwrite your current decompile and oobe with the ones from this archive, i have set the variable in oobe.cmd to Yes to skip ram checks in MRP for you to test. Please note this is experimental and may or may not work. If the variable is set to anything other than Yes then MRP will just ignore the setting.
Have also uploaded this 159 rc7b archive to the beta test areas if any tester want to try this new ram skip variable No other changes from 7a made. It is just a simple test for the variable and mrp will skip the memory checks, same as when a VM is detected but a bit more advanced. It will mention in the early and debug logs that the variable was set and ram checks have been skipped. The log may look odd and i will tidy that up if it skips ok and no other issues.
Happy new year everyone. Im hoping mine going to be better, i dont think i can get much worse than 2024 was
Uploaded 159 RC8 for beta testers Updated the enable network adaptors so it tries twice on each attempt to enable. Added new info to the debug log so early on it saves some info to the log to show if the AddonManager has started to run, has aborted or been erased = no debug1 log.