The hard disk has a cache in hardware that handles data that is read frequently.
There may also be a drive cache in the software. When this feature is enabled for a device, the process moves to the cache as it is being written to and lazily to the hard drive. Similarly, reads would first read from the cache. This means that the write might not be committed even though the system sees a file written to a device. For this reason, you should tell the operating system that you want to remove the device to make sure that it writes before you remove it. Yes, this was enabled by default for USB drives on Windows.
The operating system then has a file cache in which some files are stored. You know that there is an API for emptying / synchronizing file streams, right? Well, this cache. And yes, depending on the operating system, this cache may persist for a while after the process that opened the file has been closed.
If code is interpreted or compiled just in time (for example, scripts for the game), there could be an opcode cache. It's also worth noting that some applications generate native images on the first pass (though they should remain valid indefinitely).
Similarly, games could be downloaded (eg, game event schedules, in-store opportunities, etc.) and even decompressed and optimized (eg textures scaled), what was downloaded … to a temporary folder from where they originated If this is not the case you are too old or otherwise invalid. No, I'm not talking about patches or updates, but about data that routinely changes.
Finally, some games use a custom caching service. The idea is to provide a unified cache solution for different operating systems and configurations. This service can remain open after the process is complete while everything is being deleted / synchronized.
I may have missed another form of caching that might occur in a Windows game. This is not a complete list.