We have been struggling with the same issue since building our FIPS server several weeks ago. We are a Compaq HP house. We have dome many tests. In most tests we can install HIPS and VSE, and the system seems stable. Then right after installing EEPC/HIPS we get a BSOD. In some cases we can get a BSOD without even installing EEPC, but this is rare.
McAfee seems to want to blame the issue on HIPS. We have an open ticket 031413-158. We have sent them a MER and a full dump from one of the PCs that BSOD.
We looked at the dump file ourselves and did find a link to some firewall files as well as some AV files. We get the same message as alexn ."..tcpip.sys"
We also install a CISCO VPN and Lotus Notes as part of our standard software. Some of our testing has included installing EEPC-FIPS without HIPS, and the system seems stable. So, we do think it probably is a HIPS/EEPC interaction issue. We have installed all the patches and hot fixes and still have the issue. HIPS 220.127.116.111 roll-up and hotfix 803520.Message was edited by: awbattelle on 3/28/13 12:11:52 PM CDT
HIPS 8.80 + EEPC 6 or 7 with FIPS mode enabled + possibly HP hardware = BSOD
Remove the FIPS switch and the problem goes away.
McAfee Please fix this!Message was edited by: awbattelle on 3/28/13 12:14:50 PM CDT
Latest testing update Update;
AV+ HIPS + EEPC/FIPS + HP Hardware + Generic Windows 7 64Bit install = Success
AV+ HIPS + EEPC/FIPS + HP Hardware + HP Windows 7 64Bit install = BSOD
Of Course, on our corporate image where we have the problem, we install all the HP drivers as a matter of course.
Message was edited by: awbattelle on 4/4/13 4:14:47 PM CDTMessage was edited by: awbattelle on 4/4/13 4:15:05 PM CDT
This issue was escalated to tier 3 at McAfee. They determined it was a Microsoft issue. We opened a ticket with Microsoft and sent them the dump file.
they gave a us an unpublished hotfix from kb2789968. This resolved the TCIP bluescreen error, but we are now seeing a fwpkclnt error in our bluescreens. We believe it to be a race condition. We now have a minidump analysis of this new message, which does seem to reference a McAfee file mfeavfk01.sys . So we think we are going to hand it back to McAfee again. Mini dump is below.
OVERLAPPED_MODULE: Address regions for 'CVPNDRVA' and 'mfeavfk01.sy' overlap
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800036bd100
fffff880`018074dc 833802 cmp dword ptr [rax],2
TRAP_FRAME: fffff88004705050 -- (.trap 0xfffff88004705050)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffffffffffffff rbx=0000000000000000 rcx=fffffa82b96ca1d0
rdx=fffffa80e5795580 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880018074dc rsp=fffff880047051e0 rbp=fffffa800de7e0c0
r8=0000000000000000 r9=0000000000000000 r10=fffff88004705290
r11=0000000000000056 r12=0000000000000000 r13=0000000000000000
iopl=0 nv up ei ng nz na po nc
fffff880`018074dc 833802 cmp dword ptr [rax],2 ds:ffffffff`ffffffff=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff8000348d769 to fffff8000348e1c0
fffff880`04704f08 fffff800`0348d769 : 00000000`0000000a ffffffff`ffffffff 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`04704f10 fffff800`0348c3e0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`04705050 fffff880`018074dc : fffff880`04705250 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x260
fffff880`047051e0 fffff880`01c1efe7 : fffffa80`0dd05520 fffffa80`e5795580 fffff880`047054c0 00000000`00000000 : fwpkclnt!FwpsQueryPacketInjectionState0+0xb4
fffff880`04705210 fffffa80`0dd05520 : fffffa80`e5795580 fffff880`047054c0 00000000`00000000 00000000`00000000 : mfewfpk+0xdfe7
fffff880`04705218 fffffa80`e5795580 : fffff880`047054c0 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffffa80`0dd05520
fffff880`04705220 fffff880`047054c0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffffa80`e5795580
fffff880`04705228 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffff880`047054c0
fffff880`018074dc 833802 cmp dword ptr [rax],2
As far as I kinow mfeavfk01.sys is a HIPS kernel level driver, usually 90% of firecore is implemented in MFefirek.sys.
Could you go in device manager and under hidden devices look for Mfefirek.sys and disable it.
After disabling see the issue.
Isn't that kinda like not installing HIPS? Which we know works. In any event, we had to move forward with our encryption project, so we just abandoned installing HIPS, and went with the Windows Firewall. This gave us some breathing room, since we had quite a few laptops waiting to be delivered that needed encryption.
We still have an open ticket with McAfee on the issue that is apparently with the developers. They recently asked for a VM that exhibits the issue. I wish they had asked for it earlier because our lab was repurposed. We are doing some migration testing, Non-FIPS to FIPS server right now, and we may be able to piggyback some HIPS FIPS testing on that procedure.
Also, there have been quite a few updates and patches to all three of the products we install, VSE, HIPS and EEPC FIPS. So, maybe it will work now. I'll let you know.
Issue appears to be solved in McAfee Drive Encryption 7.1. It does run in FIPS mode, but has yet to be officially certified by Uncle Sam. I'm attaching a document that details our final findings. It seems the issue was traced to a specific very old EEPC driver file (From EEPC 6.1X) that only gets installed when in FIPS mode.