The operating system comes with a set of "default trusted root CA". This is how a Web browser can connect to existing HTTPS Web sites and be content with their certificates without requiring the user to do anything special with his trusted CA. Similarly, the "OS update" mechanism will use the same principle: it will accept an update only if it comes from a trusted server, with a notion of trust which is relative to a public key which is already known to the machine. One may note that OS updates may include updates to the store of default trusted root CA.
Of course, this raises the question of how the OS got there in the first place. All these trusted root CA only move the problem around; trust still has to start somewhere. Usually, a physical medium (say, a DVD) is involved; even more usually, this is done in the computer factory, and the user gets a computer with a pre-installed OS.
If the root CA you are talking about is not part of the "default trusted CA" (i.e. that specific CA did not make a deal with Microsoft to be included by default), then the trust system is bootstrapped by a manual procedure: when the root CA is installed, the machine asks for confirmation to the user; a thumbprint of the new certificate is displayed. The thumprint is a hash value computed over the complete encoded root CA certificate. The user is then supposed to check that the displayed hash value matches a value which was communicated to him through some out-of-band mechanism (e.g. with the on-paper documentation).
Trust must start somewhere, but, thanks to cryptographic hash function, that "somewhere" can be a value small enough to be handled in the physical, non-computer world (a human user can verify that a 40-character hash value matches that which was printed on some paper).