We have the same problem during our rollout. I thought it was EEPC (since the errors are related to writing to the hard drive), though we have EEFF installed as well. Did you ever get this problem resolved?
We are starting back up on our deployment and are sitll receiving the same errors with the latest 4.0.1 verison. McAfee's engineers and development team is still working with us on the issue. It has been almost three months since you posted to this discussion but have you been able to resolve this issue or have any clues? McAfee has asked us to turn off write caching on the hard disk as a troubleshooting countermeasure. We will see.
I was told they were releasing a new version and they thought it might help. I have removed EEFF from the workstations with this issue and I haven't redeployed it with the newer version yet.
Since we have workstations crashing in only one department, I was able to query our software database for applications that unique to that organization. I found the following installed on the computers that have been crashing and nowhere else:
IBM CICS Universal Client
IBM Personal Communications
PKZIP for Windows
You don't happen to have any of these applications installed on the machines you are having difficulties with, do you?
No, we have none of these applications installed on our systems. There is no rhyme or reason for these errors. You could have certain applications running one day and different applications the next when the error occurs. The errors would occur a week apart from each other or within minutes/hours. The issue occurs in any department and regardless of the system model. We cannot reproduce the issue but here is what I think is happening.
1. An API call is made and requests file system access to a file or folder.
2. The file or folder is presented to the EEFF filter driver.
3. The EEFF filter driver hangs and creates a "disconnect" from the call and the file system.
4. Windows reports this "disconnect" as a write/delay error.
I believe the total NTFS access failue is caused by Windows accessing system files and the EEFF filter hangs. I was thinking that WMI calls from our applications could be a problem. Write caching may also be a catalyst.
I cannot prove any of this so I am counting on McAfee engineers and development to save the day.
Safebootninja, we are experiencing something similar - very sporadic write delay errors when writing to C:. No data can be written to the drive after this, so of course there is nothing in the event logs and eventually the box will blue screen. It only occurs on XP boxes with EEFF installed. We have a combination of 3.2.6, 188.8.131.52, and 4.0 patch 1 (with and without HF 820173). I don't know if we've ever seen this on SBCE 3.x but it happened to 2 machines with 4.0 and all updates (including HF820173) just last week. We do not use 4.1 and can't upgrade at this time.
We aren't convinced EEFF 4 is causing this, although it definitely is a factor as it does not happen without that SW installed. We've had to stop deployment of the product and have spent months on this, complete with a ticket with Microsoft, onsite visits from McAfee engineers, and assistance from Dell.
We can identify no cause or commonality between the affected systems, and it can be months between incidents. Microsoft asked us to collect a kernel dump but we could not reproduce the error using McAfee-supplied test scripts although we tried for many weeks on more than 1 machine.
We use XP SP3 on most of our systems, and that is where the error occurs. We have a percentage of users on W7 professional and have never seen this error on those platforms.
Microsoft recommended a HF for NTFS.sys but it did not help.
For completeness I will mention we use EEPC 5/6 but don't think that has any influence. Oddly we aren't even using EEFF for anything other than removable media encryption - no files or folders on the hard drive should be touched by EEFF. That's what EEPC is for.
It would be great to know if anyone has had any insight to this. We may have to abandon EEFF and go with another product but would rather not. However, business needs mandate encryption so we're going to have to solve these errors or come up with another solution.