Repository navigation
Working timebomb with nulled expiration date at SharedData on 6.2.7880 #5
Description
Activity
Will any Win8 builds log me off when there is no activation, but the timebomb is disabled?
Will any Win8 builds log me off when there is no activation, but the timebomb is disabled?
Logging off when unactivated is removed at Vista SP1 in retail builds, which well predates Windows 8 development. 7880 didn't log me off, and later builds which photos posted at README.md doesn't either while having timebomb actually removed.
7880 just crashed with 0x109 BSOD as well. So the issue is indeed similar.
7880 just crashed with 0x109 BSOD as well. So the issue is indeed similar.
0x109 is caused by PatchGuard, basically a mechanism to prevent unauthorized patches to kernel. It's actually the other side of the medal in case of #2, with the first side being the timebomb killing itself, hence why #2 is closed as wontfix. This build though differs by still having a working timebomb according to you saying that it still BSODs after two hours.
When I did get the 2 hour BSOD. it was using something else, sorry for the confusion. I can try it with this driver. I will keep it on for two hours to check.
When I did get the 2 hour BSOD. it was using something else, sorry for the confusion.
If it was 0x98 END_OF_NT_EVALUTION_PERIOD, it is by timebomb.
I can try it with this driver. I will keep it on for two hours to check.
Driver has no effect so you can try with just base system running at current date, after 2 to 2.5 hours it should bugcheck 0x98 if it has a working timebomb.
The way I got 0x98 was trying the "replacing spp files" method. It did not work. The timebomb appears to work in this build. I have not checked with the kernel driver.
I reinstalled with correct date and then set the date to current, and unlike #4 (comment) it still has an expiration date. Now I wonder if installing at current date breaks it entirely...
It just rebooted with 0x109 again. Mine is missing the expiration date with the driver installed.I have a feeling that just reinstalling at current date effectively breaks the timebomb without need to do anything else. Because when I forgot the set the date back, it didn't have any expiration date set, but when I installed at a date before expiration and then set the date to current, it kept being there.
I can try right now. Let me wait for this to install and I will go from here. I will just make sure to disable automatic restart.
I also reinstalled at current date to make sure, and it is indeed gone. This time I also checked the internal structures from debugger and they were also zero, proving that timebomb is gone and refuting my guessing at the top.
I left it for 6 hours like that and it is still going.
Great then. I'm closing this as solved. I also updated readme last night.
This build, while initially looks similar to #2 , it actually differs from it by still posessing a working timebomb (according to @JannGold) as documented in #4 . Further investigation is required and will take place after I finish smoking while this build installs again.
One guessing of me is kernel internally still holds an expiration date while it's nulled on SharedData, which I have a solution for (albeit not perfect, but better than nothing).