c3direct

Hi Peter, From what I can gather from my own situation and the descriptions of others on this forum, all you need is a combination of 3ware controller, Hyper-V host, and Hyper-V guest. In our own environment, we are running two different versions of Hyper-V (Windows 2008 R2 on one and Hyper-V Server 2008 on the other) on two different 3ware controllers that are at two different firmware revisions and driver revisions, so I don't believe you need to be too picky about the specifics. All of our Hyper-V guests are Windows 2008, so I can't be 100% sure whether or not that's requred, but from the other posts I don't believe it to be the case. So, if you install W2k8 or W2k8 R2 (or even Hyper-V Server, although it lacks a GUI making things a bit more challenging to troubleshoot and manage in a test environment) on a physical machine using a 3ware 9650 RAID controller and create a Windows guest and then install ESET into that guest (and possibly the host as well), you should be able to recreate the issue. The virtual should blue screen within a matter of minutes of boot time. Again, the time frame during which this was introduced is pretty well-defined, so I don't think you'll have a lot of code changes to look through to find this issue.

Hello Peter, I'll see if I can find a dump file, but it sounds as if none of us are really sure how to provide this to you in such a way that it will be meaningful. Can you provide or link to instructions? Also - we have pretty thoroughly narrowed things down to the point that it should be relatively easy to replicate in your own environment. 3ware controllers should be readily available from eBay for a reasonable amount if you don't already have one available. Then you could take all the blue screen dumps you'd like. It's a bit of a challenge to ask your customers to let their production servers blue screen a few times in order to collect data, so a test system in a controlled environment would be a win-win. However, I'm not even sure that much in the way of dump data is necessary. I assume your developers keep track of changes and updates that are released. This change was released on Sep. 5, 2013 and almost certainly has to do with aligning one or more buffers to a DWORD boundary. That information alone should be enough to start tracking down what changes were made that may have created this issue. Let us know how to get information to you, and I'm sure we will do our best to provide you with additional data as we are able.

I can report that the double buffer workaround seems to be working. Anecdotally, I do not believe the performance has been significantly affected for the end users. @Willtech - I'm afraid I'm not at liberty to distribute a development file. I'm not 100% sure the file correlates to this problem, so I would hate to distribute something that causes problems. Perhaps if ESET believes they have a fix in place, a representative could post the file or a link to the file.

UPDATE: I have received some information from our supplier that ESET may know what is causing this issue. I am not 100% sure if this is a direct correlation, and I have not yet had a chance to try the solution, but there may be a problem with the eamonm.sys driver file. There is a development release out that he sent me to try, but it may be a day or two since I can only do this after hours. There is not currently an installation package fix for this issue. I did try enabling the DoubleBuffer registry key on the host machines this evening, and ESET was able to install and run without the crash. I am running with that as the workaround until implementing a complete fix. Thank you, socha, for the suggestion!

We have experienced identical issues on four Hyper-V guest machines (all Windows 2008) across two physical server (both have 3ware RAID controllers). This did occur on Sep 5, as others have pointed out. One host machine (Windows 2008 R2) has ESET installed and does not seem affected by this problem. The BSOD we saw was consistently coming up with 0x000000F4, although I did not gather much more information as it was a work day, so I needed to get the servers stable by uninstalling ESET. This is a pretty big deal, so hopefully developers can look at what was introduced on Sep 5, 2013 that could impact servers in such a way. If the suggested workaround above works (I am also hesitant to try a 2 year old solution on a new problem) perhaps ESET introduced something that impacted DWORD alignment of buffers. Socha - did you uninstall on the host or the guests (or both)? If I could keep the guests happy and protected and uninstall on the host, that might be okay for a short-term workaround but I'd rather not play roulette with the servers if I don't need to. Blue screens and Exchange don't get along from time to time.