Some new PID's: 55041-00142-026-982506-03-1033-3790.0000-0962010 55041-00152-339-725949-03-1033-3790.0000-0972010 55041-00140-015-871562-03-1033-7078.0000-0992009 55041-00142-026-826687-03-1033-6000.0000-3472006 55041-00152-105-000223-03-1033-6001.0000-0692009
I see. Thanks for making thing clear, I thought you meant: 1222009 means 12/2/2009. Sorry I misunderstood you. You are right.
Why don't they match the ones you posted before though? 55041-00168-305-190595-03-1033-3790.0000-2692009 55041-00168-305-246209-03-1033-7600.0000-0522010 55041-00168-305-100667-03-1033-6002.0000-2372009
@CODYQX4 BTW, As i already said, the method that I use to get a null KMS CMID when all 5 rearms are used up, causes the Office to go to Notification mode. It's not much of a deal, cause with reams used up and Office in OOB_Grace, It will only be a maximum of 30 days till Office goes to notification mode anyway. But I still want to know that if you have a method that let office stay in OOB_Grace mode while nulling CMID at the same time?
No, I don't have any method to null the CMID and keep grace without rearming. About PID testing though, I used CMID test to brick with your null PID, tested with ZWT PID, failed, testes with MS PID (on the troubleshooting link), failed, started trying the 3 PID's I quoted and the second one worked in one shot.
55041 doesn't mean KMS Host. All of MS's recent products use it. As a matter of fact, that value isn't even used in our Key Checker, it's arbitrary. You have to pass a 5 digit value but it has no effect on the process. We have switched back and forth between 82503 (used in PID for office in the registry) and 55041, which is the starting value in every Extended PID I've seen.
Good to hear that. So basically are you saying that you agree on that fact that Persistent 8007000D error is now gone for good with me?
What I am saying is I have 2 methods at my disposal to fight it. 1. The idea we agreed on that getting the system in a state with no CMID so we can backup and change at will until we activate. 2. Changing PID to some of what you posted, as it seems trying enough PIDs results in success. So a longer list of good PIDs should be made. I feel the PID method should be tried first as it requires no modification to the Office 2010 licensing/backup/rearm.
Current List: (ZWT+MS+All you posted so far) 55041-00096-199-000004-03-1033-7600.0000-3632009 55041-00168-305-190595-03-1033-3790.0000-2692009 55041-00168-305-246209-03-1033-7600.0000-0522010 55041-00168-305-100667-03-1033-6002.0000-2372009 55041-00142-026-982506-03-1033-3790.0000-0962010 55041-00152-339-725949-03-1033-3790.0000-0972010 55041-00140-015-871562-03-1033-7078.0000-0992009 55041-00142-026-826687-03-1033-6000.0000-3472006 55041-00152-105-000223-03-1033-6001.0000-0692009
Something else I'm checking, is being able to read/write PID from running process. I found a nice library and being able to change it on the fly is better than stopping/starting. I'll see if I can get that working.
Anyone know where in memory the PID is stored? I need to set an IntPtr like 0x00000000 to it to read/write it.
I still insist that we already found the heart of ZWT keygen's problem and the cause of failure in activation. And that persistent error is no longer persistent coz we know how to circumvent it.
Here is two new PID's: 55041-00168-313-440506-03-1033-7600.0000-2242010 55041-00142-026-098258-03-1033-6000.0000-3392006