CAs are pre-loaded on the system, but how is it able to get intermediate certs?
An X.509 certificate may contain extensions, one of them called Authority Information Access, which contains "pointers" to the certificate for the (intermediate) CA that issued it. In your case, the AIA extension is present and contains the following URL:

http://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt


Windows simply sends an HTTP GET request to that URL, and tries to interpret what it obtains as an encoded certificate. Which is the case. Windows can then verify that the intermediate certificate is indeed a valid issuer for your certificate (the signature is valid, the subject/issuer names match, the validity dates are correct, and so on...). Once it has obtained the intermediate CA cert, it repeats the process, until it hits one of the preloaded root CA.

The certificate viewer of Windows can show you such URL (see the "details" pane). Alternatively, you can decode the certificate structure to see for yourself the gory details (personally, I use my own tool called DDer).

Amusingly, this feature can be used to make, in some circumstances, a remote machine issue HTTP GET requests at URL of your choosing (but only GET, not POST, and only HTTP, not HTTPS; and you don't get to see what is obtained). For instance, if there is a Windows-based SSL server that asks for client certificates, then a malicious client may submit a phony certificate that makes the server issue on HTTP GET at a URL that will be interpreted by the server itself (and thus may contain "internal" IP addresses, or even "localhost").