Sigh… 
Is it fixed in 6.5? Haven’t updated yet. Just went through the full scan again with 6.0.5.
Oh, even better. After going through the rescan, Cubase managed to corrupt my VST list so when I opened the project I was working on it told me that Ozone 5 couldn’t be found and then crashed. After that I rebooted, reloaded Cubase and opened the project again… and it told me that every VST in the project was missing (although this time the project loaded).
So… deleting the VST2xBlacklist and the VST2xPlugins and going through a full rescan… which means (with a bunch of legacy 32bit bridged plugins with jBridge) I will not be working on music tonight and instead watching it scan for an hour.
Double sigh.
We (gmt+1) change in 2 weeks 
But yes, it’s annoying and unnecessary
Is this a freebie in special Cubase packs? I’ve never seen it.
The first time you run Cubase after a daylight savings change it does some sort of VST rescan. Not a full rescan, but enough to be noticeable. An extra several minutes on boot.
Only this time something bad happened–not sure what–to make the scan fail in some strange way which corrupted the VST list.
To fix it I just deleted the above mentioned files and because jBridged VSTs take a long time to scan and I have a pile I keep around on the off chance I need to load old projects that meant instead of working on my latest song for the hour before bedtime I had to watch Cubase (successfully, this time) scan all of my VSTs for an hour.
Ah ha. The bridge maybe? Some 32 bit protocol may be involved? Scanning for 32 AND 64 bit versions of the same files?
I’ll have a quick stroll around the net and see if any other apps suffer this and if there is a possible fix.
Sounds like one of those tiny insignificant looking Windows / BIOS settings that you get to notice once every ten years and next day you’re looking for them again (for five years).
Five minute check.
The bug is caused by a logic error in the C-Run-time library’s cvtdate helper function
From the Microsoft site. It’s old, could be outdated but looks like a ballpark runner. Could be something in one of the .dll files or some VSTs themselves. If I’m reading that rightly it looks to be a problem in part of a program / compilation app so if it’s a bug in Cubase (I think that’s unlikely, just me though) or any related VSTs it would be introduced via their programming package which means we ask them to fix that bug and Steinberg have to ask their programming package makers to fix it in turn. My two peas.
Thanks for reminding me this is going to happen tonight… will get some snacks ready prior! 
Yea, I totally forgot or I would have booted up Cubase hours before my recording session. I should set a semi-annual calendar reminder for myself!!
There were previous discussions in the old forum, where it was claimed that a re-scan isn’t triggerred if you switch off the automatic updating of the clock (for winter/summer time changes) and make the change manually.
And here’s an interesting extract:
Curious.
Steinberg has never really explained why this happens. I bet you it’s a one-line code fix.
It boggles my mind how a Windows behavior around daylight savings time, call it bug or “feature”, could make Cubase force a VST rescan. Kind of leaves you wondering who to blame. I have no doubt how either Steinberg or Microsoft would characterize it.
I take that back. Seems it is/was a known issue for MS, if that is truly the behavior that is causing this. MS have issued a fix. See the KB article…
http://support.microsoft.com/kb/214661
If this is true, and I am understanding correctly, the onus would have been on Steinberg (some 5 years ago or any time afterwards) to simply update their dev environment with the latest Visual Studio service pack and recompile Cubase.
Note that that was an article for VS 6. MS’s latest is VS 10 now.
Since most of what I just wrote would make little sense to any person of logic, I’d have to still characterize this source of this issue as from an unknown source.
… says the symptoms are …
The C-Run-time Library date/time functions might fail to calculate the correct time during the first week of daylight saving time beginning April 1, 2001. The bug corrects itself after one week, on the following Sunday. This bug is not related to the year 2000 problem.
So, for that to be the cause of the problem, Cubase has to (a) get flummoxed by the failure to get a correct time from the routine, and (b) respond by re-scanning?
To a layman like me, it seems odd that ‘(a)’ would have to cause ‘(b)’.
And I wonder how that relates to the apparant workround (if it’s real) of setting the time manually .
Cubase: OMG, the system clock is exactly one hour off from what I expect it to be! Red alert! Should I suspect foul play and invalidate the user’s eLicense? No, I think I’ll force a VST rescan.
User: STFU and play back my tune.
LOL
Anyway, is anyone going to try switching off Window’s automatic clock adjustment and do it manually, to see if, that way, the re-scan is avoided?
I have never had this scanning problem happen to me.
I just checked, and my Window’s automatic clock adjustment is switched off, for what thats worth.
Aye but if it’s in the compiler code they would have to wait for them to fix it. Also mentioned on the M’soft page I quoted is that it sometimes resolves itself after a week. Probably after a Windows update.
Hunting a one-line code fix down could take some considerable time. A few seconds to fix and a week looking for it. Cubase code isn’t small.
They just need to do a search for this.
if (GetDate() != mExpectedDate)
{
vstScanner.DoSomethingTotallyRandom();
}
Double LOL