I get a buffer overflow from C:\Windows\syswow64\explorer.exe after each game installation since yesterday. As soon as the installation is finished, I get the overflow msg. Then, I checked the Comodo defense history and saw this:
C:\Users\xxx\AppData/Local/Temp/_isEE6.exe → Create Process → C:\Windows\syswow64\explorer.exe
I checked “Skip this application in the future” and didn’t get the message after that. Is there any way to undo that to see if the problem is still there?
As soon as a installation of a game (Virtua Tennis 2009 or Anno 1404) completes, I get the Comodo message box I posted above. Never occured while I was surfing a watching a video. I just want to know if it’s a false positive or not…
Thanks. So you think it’s rather because of a corruption issue than a attack? I remember that I installed some Windows Vista Updates a couple of days ago. It’s odd that when I boot Vista 64 I only have one explorer.exe (from c:\windows), but after an installation I also see the other one from c:\windows\syswow64. When I choose terminate, the system runs fine nonetheless.
So what’s your suggestion? Block access or choose “skip in the future” in the Comodo msg box?
Are there any events in the Windows event logs? The only thing that I’m concerned about is the _isEE6 temp file. Have you checked that location to see if the file exists and if so has any identification?
Initially, I deleted the file, but there are new files in the folder with the exact same structure which are defined as Macrovision Corp. So it seems it was just a copy protection from my games.
I just installed Vista SP2, maybe it’s fixed now.
Edit: Nothing special in the Windows event logs.
Edit 2: I uninstalled something and got it again. As soon as the install shield starts, the other explorer.exe pops up.
Edit 3: Would it help if I installed a clean explorer.exe from someone with Vista x64?
I’ve just been doing a little reading around this and I came across something I believe explains, to some extent at least, what we’re seeing:
In x64 versions of Windows, a process that starts from a 64-bit executable such as Explorer.exe can only load Win64 DLLs, while a process started from a 32-bit executable can only load Win32 DLLs. When a Win32 process makes a call to kernel mode—to read a file, for instance—the WOW64 code intercepts the call silently and invokes the correct x64 equivalent code in its place.
Of course, processes of different lineages (32-bit versus 64-bit) need to be able to communicate with each other. Luckily, all the usual interprocess communication mechanisms that you know and love in Win32 also work in Win64, including shared memory, named pipes, and named synchronization objects.
I’m inclined to say that it may be a ‘feature’. If there are no additional manifestations, I’d let it do it’s thing, but with the provisio of keeping a close eye on it.
One last thought, what are your D+ settings for explorer(s).exe
I got news: While I played Call of Juarez 2 I had a lot of crashes and finally a blue screen 0x0000003B. After that I ran the Windows Memory Diagnosis + Memtest and a memory occured both times. So maybe it was a RAM problem after all which caused all the problems. Who knows… I get my new memory next week, because it wasn’t on stock.