Since the thumbnails are under INetCache, maybe it’s some Windows cleanup processes that removes them.
Try creating a new darktable-cache folder somewhere under your user’s home directory. Then modify the shortcut used to launch darktable, and add the command-line option --cachedir c:\path\to\darktable-cache.
Note that you’ll need to discuss the same option for the thumbnail generation script, too, if you decide to use it (I don’t use that script, thumbnails are generated as needed).
@KIRSJ
To try to pinpoint your problem even more,
place a small film roll in your C: user area
(i.e. @rvietor’s advice with a specific location added).
Have fun!
Claes in Lund, Sweden
There are plenty of windows users here. None have reported this problem. There is something different in your PC. You need to provide more information for us to help or try something different. For example:
Move some images to your local drive. Does it happen on local or only USB?
Start dt with -d all on CMD prompt. Error msg?
Antivirus? Any logs there?
I have created a new cache as suggested - and it runs for now.
Will return in a day or so and tell if it survived the night.
Starting Darktable with a reference to a new cache seems to work fine - also ‘the day after’.
I now start from a shortcut on the desktop calling a small batch file. It works fine and I have direct insight with the thumbnails - even when system files is tagged to not show.
Very usable, Kofa.
Then dt should not store files in INetCache, as they will be removed 
It is a cache. It should be temporary.
And can you explain why this is only affecting one people?
If a bug, then patch please. I’m no using Windows.
Inetcache is one of the default locations the os gives to an application , if the application asks 'where can i store non-critical files '.
Trey are maybe removed by storage sense (the disk cleaning if the drive is almost full), or an external tool that is too eager to clean up stuff (like most external cleaning tools are ).
Inetcache is the correct place. Just don’t run a program that removed all application cache, unless you want caches cleared :).
For a web browser.
Brave, Chrome, Firefox and RawTherapee all store their cache under %LOCALAPPDATA%\[<name of publisher>\]<name of app>\some-subdirectory, e.g. %LOCALAPPDATA%\Mozilla\Firefox\Profiles\5ic4qxjh.default-release\cache2 or %LOCALAPPDATA%\RawTherapee\cache. Filmulator’s thumbs directory is also there.
Darktable stores some files under %LOCALAPPDATA%\darktable, too: namely, those that on a Linux box would be under ~/.config/darktable (settings, library, colour profiles, styles). Maybe making an exception for Windows and moving the cache there, too, would make sense. Alternatively, use %HOMEPATH%\.cache\darktable or %USERPROFILE%\.cache\darktable. %USERPROFILE% seems to be the preferred option, at least according to Prefer USERPROFILE over HOMEDRIVE/HOMEPATH · Issue #23 · mitchellh/go-homedir · GitHub.
Under INetCache, I found files from Darktable and Gimp (incl. G’MIC and GEGL), as well as MS Office (presumably from files opened/downloaded from Office apps).
It’s not ‘the’ browser folder .
It’s an official place to put temporary files per application. It’s not something dark table chooses, I’m guessing dark table ‘asks’ windows with the win-sdk-api.
I have other programs there putting files there.
appdata is for storing application settings (persistent data ) that migrates between computers in a network environment. (So ‘per-user’ settings ).
localappdata is for the same put meant for per-device settings. Lots of applications use this to store cache , but it’s meant for more permanent non-volatile data . (Even Edge stores cache there , but that’s because it’s a chromium copy :)).
The whole idea for the inetcache folder is that applications write ‘volatile’ per-machine data there . Data that’s ok to delete / not a problem if it goes missing. Backup tools can ignore them, storage-sense can auto delete it if space is low , restore-points can ignore them, etc…
Of the inetcache folder was hardcoded by the DT devs, then i might agree that it’s not correct. Apps should 'ask windows ’ for the location of certain folders depending on the type of data.
But i have a feeling (didn’t check it ) that this is exactly what the devs are doing (or maybe glib is doing it for them :)).