Windows XP’s initial user picture was not chosen by you, and it was not chosen by the system’s taste. It was chosen by a random number generator, seeded by GetTickCount().
The mystery surfaced on December 11, 2025, when a user on X, going by the handle Xeno (or XenoPanther), asked the platform directly: “Has anyone attempted to figure out the RNG for how Windows XP determines what profile picture is used on first account creation?” The post prompted a detailed written explanation from the author, who laid out the full mechanics in response.
The short answer is that the picture was picked via a specific algorithm, using a specific random function, with a specific seed. The long answer involves reservoir sampling, a clever bit of math, and a safety cap at 100 files.
The Random Number Generator
The engine behind the choice is a Windows function called RtlRandomEx. This is a pseudorandom number generator, which means it does not produce true randomness. Instead, it takes an initial value, called a seed, and runs a mathematical operation on it to produce a sequence of numbers that look random.
The seed for this particular operation is the current value of GetTickCount(). That function returns a value that changes over time, making it a common and cheap way to get a changing input. It is different every time you call it, at least in theory.
So the process is: the system reads the tick count, feeds it into RtlRandomEx as the seed, and then uses the resulting stream of numbers to decide which picture to show.
The One-Pass Selection
The algorithm itself is described as a “one-pass random selection algorithm.” That phrasing matters, because there is a simpler, more obvious way to do the job that the engineers deliberately avoided.
The naïve approach would be a two-pass algorithm. First, you count all the pictures in the folder. Second, you pick a random number between 1 and that count. Third, you iterate through the folder again to find the picture at that index.
The one-pass approach does not do that. It goes through the folder exactly once, and it decides on the fly whether the current picture should be the winner.
The engineer explained two benefits of this design. The first is efficiency. The bottleneck in this operation is the file system. Calling into the file system is slow, so reducing the number of calls from two passes to one pass reduces the work.
The second benefit is robustness. If the number of files in the directory changes while the code is running, the two-pass algorithm can break. If you count five files, then a sixth file appears, and then you ask for the file at index five, you might get the wrong result. The one-pass algorithm does not care about the total count, so it avoids that complication entirely.
Reservoir Sampling
The one-pass algorithm is not a bespoke invention. It is a special case of a well-known statistical technique called reservoir sampling.
Reservoir sampling is a method for selecting a random sample of k items from a list of n items, where n is either very large or unknown in advance. The classic use case is selecting a random subset of lines from a huge log file, or a random sample of records from a stream of data that is still arriving.
In the general case, you keep a “reservoir” of k candidate items. You go through the stream one item at a time. For the first k items, you put them all in the reservoir. For every item after that, you randomly decide whether to replace one of the items in the reservoir with the new item.
The Windows XP case is the simplest possible version of this, where k equals 1. The reservoir holds exactly one item, the current winner. The math simplifies to a single decision per item.
How the Math Works
The engineer provided the actual logic in pseudocode. It looks like this:
selectRandomFromIterator(iterator) {
var count = 0;
var winner = null;
while (iterator.moveNext()) {
++count;
if (uniform_random(min: 1, max: count) == count) {
winner = iterator.current();
}
}
return winner;
}
The logic is built on a simple observation about probability. In a collection of n items, the last item has a 1 in n chance of being the one you want. If it is not the one, then you need to pick randomly from the first n minus 1 items.
That is a recursive definition. To pick from a list of n items, you first pick from a list of n minus 1 items, and then you decide whether to switch to the nth item with a probability of 1 in n.
The code plays that recursion forward. It starts with the base case: a list of 1 item. With only one item, that item must be the winner. Then, as it reads each new item, it rolls a virtual die. The die has a number of sides equal to the current count. If the die lands on the highest number, the new item becomes the winner.
Here is how it plays out with a real example. Say the folder has three pictures, A, B, and C.
The code reads A. The count becomes 1. The random number is chosen from 1 to 1, which means it is always 1. Since 1 equals the count of 1, A becomes the winner.
The code reads B. The count becomes 2. The random number is chosen from 1 to 2. If it is 2, B becomes the winner. If it is 1, A stays the winner. The chance of B winning is 1 in 2.
The code reads C. The count becomes 3. The random number is chosen from 1 to 3. If it is 3, C becomes the winner. If it is 1 or 2, the current winner stays. The chance of C winning is 1 in 3.
What is the chance that A ends up as the final winner? A won the first round for sure. Then B had to lose, which happens with probability 1 in 2. Then C had to lose, which happens with probability 2 in 3. Multiply those together: 1 times 1/2 times 2/3 equals 1/3. Each item ends up with exactly a 1 in 3 chance. The math checks out.
The 100 Picture Cap
There is one more safety feature in the code. The selection process stops after sampling 100 pictures.
The engineer explained this as a guard against pathological behavior. If somebody were to put a million files in the Default Pictures directory, the cap ensures the process avoids that kind of problem. The exact failure mode is not spelled out, but the intent is clear: keep the operation bounded no matter what is in the folder.
The practical effect is that files beyond the 100th sample are not part of the selection process. The source does not detail the precise consequence for those files, only that sampling stops at 100.
Two Benefits of One Pass
The engineer identified two specific advantages of the one-pass design over the naïve alternative.
The first is efficiency. The two-pass method requires counting every item, then iterating again to find the chosen index. That means twice as many calls into the file system, which is where the bottleneck lives. The one-pass method cuts that work in half.
The second is stability. If the number of files in the directory changes while the code is running, the two-pass algorithm can break. You might count five files, then a sixth appears, and then you ask for the file at index five and get the wrong result. The one-pass algorithm does not depend on a total count, so it avoids that complication entirely.
Why the Design Holds Up
This is a piece of trivia about an operating system that is over two decades old. Windows XP is long past its support window. Yet the question still draws attention, and the answer is a small window into how operating system engineers think.
The choice of a random picture is a tiny feature, barely noticeable, easily ignored. But the engineering behind it is not lazy. The engineers did not just call a random function and pick a number. They chose a specific algorithm with specific properties, they understood the trade-offs, and they added a guard against a corner case that would never happen for a normal user.
| Algorithm | Passes | Handles changing file count | Efficiency |
|---|---|---|---|
| Naïve two-pass | Two | No | Slower, more file system calls |
| One-pass reservoir sampling | One | Yes | Faster, fewer file system calls |
The two-pass approach is easier to understand, but it is brittle. The one-pass approach is slightly harder to wrap your head around, but it is robust and efficient. The Windows XP team chose the robust one.
If you created a Windows XP account and got whichever picture the system handed you, you did not get it because of anything you did. You got it because the random number generator, seeded by the current value of GetTickCount(), happened to land on that file.
The question from Xeno has an answer, and now the answer is on the record. The initial user picture in Windows XP was selected by RtlRandomEx, seeded by GetTickCount(), using a one-pass reservoir sampling algorithm with a cap of 100 files.
That is the whole story. It is a small story, but it is a complete one.
Source: devblogs.microsoft.com
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.