Are you going to add leak tag details? Though, there's leaked image of half-leaked tag. It seems to be just non-cap letters and numbers.

I will if I can figure out what the leak tag is called and what its function is.

Part of Rights Account Certificate (RAC) GUID, used to enable locked features on a pkey-per-employee basis. Can be traced, unless the system is installed with default key (product.ini), then untraceable.

On key installation and activation Security-SPP logs the process to Application Event Log, the process can be seen detailed, described below:

On SPP (Software Protection) check load, it initalizes the status for these service objects, to check then if the installed key comforms to one of these algorithms:

C:\Windows\system32\sppwinob.dll, msft:spp/windowsfunctionality/agent/7.0, 0x00000000, 0x00000000
C:\Windows\system32\sppobjs.dll, msft:rm/algorithm/phone/1.0, 0x00000000, 0x00000000
C:\Windows\system32\sppobjs.dll, msft:rm/algorithm/pkey/2005, 0x00000000, 0x00000000
C:\Windows\system32\sppobjs.dll, msft:spp/TaskScheduler/1.0, 0x00000000, 0x00000000
C:\Windows\system32\sppobjs.dll, msft:spp/volume/services/kms/1.0, 0x00000000, 0x00000000
C:\Windows\system32\sppobjs.dll, msft:spp/volume/services/kms/licenserenewal/1.0, 0x00000000, 0x00000000

and then checks the Activation ID for validty.
If it fails, the Genuine Status for the given Application ID will be set to non-genuine, until installation of a genuine key.
It also sends an alert to Winlogon, that Windows is running in Notification period. Winlogon then enforces the policies for a non-genuine system (i.e. removing the background, displaying non-genuine notice on watermark area, popping notifications about counterfeit software, etc.).

At the time of installation of a genuine key, the following procedures happen:
1. Installation of a Proof of Purchase, ACID and PkeyID referred here
2. Check validty and type of the key with msft:rm/algorithm/flags/1.0 and msft:rm/algorithm/pkey/2005
3. Acquisition of Rights Account Certificate (this later check on msft:spp/windowsfunctionality/agent/7.0)
4. Installation of two XrML 2.1 Licenses for the received Rights Account Certificate : {msft:sl/RAC/ACTIVATED/PUBLIC} and {msft:sl/RAC/ACTIVATED/PRIVATE} License ID keys. Both keys tying to the given SKU ID as a Product Certificate GUID.
5. Acquisition of an End User License
6. Installation of two XrML 2.1 Licenses {msft:sl/EUL/ACTIVATED/PUBLIC} and {msft:sl/EUL/ACTIVATED/PRIVATE} License ID keys. Both keys tying to the given SKU ID as an End User License.
7. Validation of the license with Windows Activation Technologies with msft:rm/algorithm/hwid/4.0
8. If passed (no several Installation IDs logged for the key), set Genuine Status to genuine for the given Application ID, if fail, set Winlogon to Notification period as described above.
9. Enforcement or excludenent of features' policies (fully customizable, example policy: Shell-InBoxGames-Solitaire-EnableGame), for the given Application ID and SKU ID. This is where SLC calls for RP-permissions for locked features.


Conclusion
The RAC succeeded the feature, that was known before as a Build GUID. On any Windows 8 build go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion. Note that the BuildGUID string is all ffffffff-ffff-ffff-ffff-ffffffffffff - this is because it is obsolete, it is is no longer used as the build identifier, the Rights Account Certificate is used instead).

Uh, are you a Microsoft employee? Still, thanks. I'll condense the info down and put it on the first page, with credits to you of course.

And for every build provided. The RAC of 6.2.7955.0.x86fre.fbl_srv_wdacxml.110228-1930 is a1b6210f837a32cf IF the key being used IS the default one (x-3MBMV, pid XXXXX-292-0000007-85519). The RAC of this

is as shown IF the same default key is used (screen shared by Chris123NT on MDL).


Typo here, 110228-1930 not 080511-1430

All of you can see the actions described above, in each one's eventlog. Key installation actions enforcement is slmgr /upk and /ipk on win7, and Genuine Center in 7955.

Though, the builds can be considered as traceable even with the default pkey, because if an employee downloads the build, his download is being logged on corpnet, and then if he leak it, the notice on the desktop takes enforcement.

For RAC naming in as a GUID is quite incorrect, because GUID is {8-4-4-4-12} but RAC is a hex (16) value. So better to call it a RAC ID, without GU (though it is written as a GUID in the eventlog entry, just an ID is printed on the desktop).

I'm not a Microsoft employee.

That is some nice information there.

Now there is no reason to keep those unleaked builds for yourself (the person who have unleaked builds).
They are not tracable.
So I expect more leaks soon.

Fixed.

That is really neat. I knew a few of the parts of the tag, mainly Major, Minor, and Build. I knew the Build number(i.e 7600 in windows 7) meant number of compile times, but I didn't know it counted from 1988. That is just interesting.

Does anyone have a program that can desifer all of this and spit all the stuff at you like in a txt file? That would be really cool. Maybe i could even work on that.

Chris123NT posted an article on it too, here: http://www.chris123nt.com/2011/04/25/wi ... explained/ .
So yes. I was very close on it, explaining the things above on this page - it's tied to Windows Product Activation things (RAC is part of the licensing system, related to WPA, WAT and other synonyms). For the tracing it's unknown how large the group is - single employee, group, dev team... because not known, how many employees have access to the internal keys and how they are assigned.

Thanks, I learned something today

I would imagine that there would be daily releases at the individual labs, similar to how most open source software has a daily build. It would be interesting to see how 'winmain' stiches all the code together, that's got to be a hell of a job considering there would be so many people trying different things in different departments, and tracking all the changes would be a nightmare (which is why it's so useful to understand a build tag).

Lots of useful info into just one Thread...
Looking at Win 8, now I think that new leaks couldn't be interesting, as long as we won't see a leaked "winmain" build...

xxxx.x.x86fre.fbl_uex(pietrovg).xxxxxx-xxxx

What does pietrovg mean in the build string?

I'm not entirely sure on this, but I think that a name in parenthesis means this this was a build compiled for or by a specific person.

Interesting post, and a must-see for anyone interested in betas.

I was looking for the Winver tag (yes, I know it isn't exactly the same, but still gives lots of valuable info), I got this:

Microsoft(R) Windows(TM)
Version 5.1 (build 2600.xpsp.080413-2111: Service Pack 3)

If I understand correctly, it would be translated to:

NT Major Version - 5
NT Minor Version - 1
Build number - 2600
Revision - xpsp?
Build lab - xpsp?
Compilation date - 13th April 2008
Time of compilation - 21:11 (9:11 PM)

What is "xpsp"? The revision, the build lab or any other thing?

And... Rights Account Certificate GUID... is this something like disabling Windows features in some build labs so if they are leaked, only the lab-related features are leaked?

xpsp in this case is the build lab, XP Service Pack. The Revision doesn't show in winver or the desktop watermark, but it is present in system files like ntoskrnl.exe.


As far as I can tell, the RAC GUID is just used for tracking Windows 8 builds as they go around.

Yes, I already thought it was the build lab (xpsp stands of course for xp service pack).

And that GUID... maybe I'm wrong, but this is going to mean problems, legal problems for Microsoft employees that leak betas, and some problems even here...

Well, the RAC GUID is traceable if a valid product key is used. If you just use the default product key that's built in, it's untraceable.

The first Windows 8 leak happened back in April, as of this posting it's mid-November and as far as I know, we haven't gotten any takedown notices.

Luckily.

----
Anyway, this things don't appear from the nothing. Microsoft has some reason to do that. Don't ask me what reason. A GUID is just a identifier, like a Product ID or a barcode, but... Microsoft could discover the source of leaks by having those build numbers... just by having the build lab tag, they don't need the GUID.

A few of the field names are slightly wrong.

The major and minor fields should be Product Major Version and Product Minor Version. Build number is Product Build and the revision or delta field is the QFE Product Build. It's only idwlog that incorrectly identifies the QFE version as "Delta".

The Build Machine is actually the name of the user that started the build. In the case of an official build, it's the name of the build lab and for a private build, it's the alias of the developer. The Build Date is a single field that contains two parts, the time and date when the build was started. The Build Date only modifies the version information, the linker still uses the current system time when linking.

You can check the WDK for further details as the Windows build environment is a much, much more advanced version of it. The fields of interest are VER_PRODUCTMAJORVERSION, VER_PRODUCTMINORVERSION, VER_PRODUCTBUILD, VER_PRODUCTBUILD_QFE, __BUILDMACHINE__ and __BUILDDATE__.

Actually, a full build is kicked off when a QFE build is submitted, it's just that the build system is smart enough to only recompile those components that change or those that have dependencies on components that change.

Not correct, coding on NT OS/2 didn't start until 1989, the last few months of 1988 were spent designing the system, as was a large part of 1989. In earlier builds of Windows NT, you could use the build number as a count of the number of times the system was compiled; now, it's not the case.

Excuse my ignorance.

Am I confusing build numbers with year of release? I mean: is 1988 a normal build number that Microsoft catched for no reason or it has relation with the year 1988?

Yes, you are. The year 1988 was around when OS/2 3 and NT were first in development iirc.