(re-posting this here in hopes that it gets some visibility)
This is an interesting issue because it's so easily misunderstood. There are a lot of things that have caused the DWH*.TMP issue. I'm really surprised none of them have been outlined in this thread, yet. There's a post by ScubaSteve early on that gives a good explanation... perhaps the implications aren't fully realized.
The first thing to understand about this issue is: It's not one, single issue. There have been many different reasons for the DWH files showing up in various locations. Ultimately, the basic reason is the same, but numerous root causes have been found over the years.
The second thing to understand about this issue is: It doesn't continue to occur because SEP developers and support engineers don't care about this issue or just can't figure it out. The truth is, it continues to occur because, as noted in misunderstanding #1, there are a lot of things that cause the issue. To date, we have fixed various root causes for the issue. We fully understand the issue and work hard to implement solutions that don't break other things at the same time. We're sorry you have this issue and, if you look, you'll find we have solutions in place.
The third thing to understand about this issue is: It's not always Symantec software's fault. This requires a little more explanation of what happens behind the scenes. When SEP gets new defs, it checks the files in Quarantine to see if there are any new remediation steps, false positives, etc. Files in Quarantine cannot simply be scanned while they're quarantined. They must be extracted from Quarantine first. The expected behavior is this: SEP extracts the files, scans them, moves them back to Quarantine. There have been cases (mostly earlier builds) where a bug in SEP would cause the DWH files to be mishandled. SEP abandons the process because it can no longer trust the files and, as it does with all files that are written to the disk, scans the file with Auto-Protect. Auto-Protect finds the virus code in the DWH file and acts on it (quarantining). There have been other cases, however, where other software (3rd party scanners or indexing services, for example) try to get in the way and cause the DWH files to be mishandled. This is something Symantec simpy cannot always avoid. We're very sorry about it and wish it didn't have to be this way, but that's just the way it is. The proper response is to fix the offending 3rd party software.
Finally, I want to address one obsurd point of advice about re-installing SEP to fix the issue. In most cases, this simply isn't required... and furthermore, no real Symantec tech is going to recommend this as a first solution. The first thing to do is look for 3rd party software that may be causing SEP to stop trusting DWH files. Setup exclusions for SEP's working directories. If that doesn't do it, purge Quarantine and SEP's working directory. If you want to be more surgical, only delete DWH.tmp files in the working directories (still need to clear Quarantine). If you simply can't stand to have another DWH detection, disable the scans when new defs arrive (not Best Practice). If you want to go even further, adjust your detection settings to not use Quarantine (also, not Best Practice). Finally, if all this fails and you still get DWH detections, re-install the SEP client. But realize you're re-installing because there's something else very wrong with the software at this point... policy corruption, permission issues, etc. At this point, you should probably be contacting Support to work on a full investigation.