Blue Screen of Death 3 times since installing ESS 5.0.94.0

Blue Screen of Death several times since installing ESS 5.0.94.0

Since installing ESS 5.0.94.0 I have experienced 3 blue screens of death after starting and running my pc for a while.

I have attached a mindump file that was generated and wondered if anyone knows why this is happening.

Any help appreciated.

Code:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\101911-20498-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`03054000 PsLoadedModuleList = 0xfffff800`03299670
Debug session time: Wed Oct 19 20:50:41.217 2011 (UTC + 11:00)
System Uptime: 0 days 1:39:08.981
Loading Kernel Symbols
...............................................................
................................................................
.............................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {2a54604, 2, 1, fffffa80065852a7}

Probably caused by : ntkrnlmp.exe ( nt!KiPageFault+260 )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000002a54604, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffffa80065852a7, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80003303100
 0000000002a54604 

CURRENT_IRQL:  2

FAULTING_IP: 
+3238333738386330
fffffa80`065852a7 8901            mov     dword ptr [rcx],eax

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  ekrn.exe

TRAP_FRAME:  fffff88008e2c520 -- (.trap 0xfffff88008e2c520)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000038 rbx=0000000000000000 rcx=0000000002a54604
rdx=fffffa80030c4f4c rsi=0000000000000000 rdi=0000000000000000
rip=fffffa80065852a7 rsp=fffff88008e2c6b8 rbp=fffffa8005c3a2b0
 r8=00000000000001fa  r9=00000000000001fe r10=fffff880009e6ac0
r11=0000000002a54604 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
fffffa80`065852a7 8901            mov     dword ptr [rcx],eax ds:d000:00000000`02a54604=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800030d01e9 to fffff800030d0c40

STACK_TEXT:  
fffff880`08e2c3d8 fffff800`030d01e9 : 00000000`0000000a 00000000`02a54604 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`08e2c3e0 fffff800`030cee60 : fffff6fb`40000188 00000000`00000004 00000000`00000000 00000000`000001fe : nt!KiBugCheckDispatch+0x69
fffff880`08e2c520 fffffa80`065852a7 : fffffa80`0658510f fffffa80`06460e00 fffffa80`0657bf38 00000000`00000000 : nt!KiPageFault+0x260
fffff880`08e2c6b8 fffffa80`0658510f : fffffa80`06460e00 fffffa80`0657bf38 00000000`00000000 00000000`062ee7d0 : 0xfffffa80`065852a7
fffff880`08e2c6c0 fffffa80`06460e00 : fffffa80`0657bf38 00000000`00000000 00000000`062ee7d0 00000000`53486d45 : 0xfffffa80`0658510f
fffff880`08e2c6c8 fffffa80`0657bf38 : 00000000`00000000 00000000`062ee7d0 00000000`53486d45 00000000`00000000 : 0xfffffa80`06460e00
fffff880`08e2c6d0 00000000`00000000 : 00000000`062ee7d0 00000000`53486d45 00000000`00000000 00000000`c0000034 : 0xfffffa80`0657bf38


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!KiPageFault+260
fffff800`030cee60 440f20c0        mov     rax,cr8

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  nt!KiPageFault+260

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3

FAILURE_BUCKET_ID:  X64_0xD1_nt!KiPageFault+260

BUCKET_ID:  X64_0xD1_nt!KiPageFault+260

Followup: MachineOwner

 

Could you upload the minidump somewhere and PM me the download link? At any rate, it'd be better if you could also generate a kernel or completely memory dump which may be necessary for determining the cause of BSOD.

 

I have sent you a pm with the link to where I uploaded the 4th BSOD crash minidump.

Your assistance would be appreciated.

To upload a memory dump would be a 6gb upload which is too big sorry

 

After several more BSOD's I de-activated the all process management of memory used by a firefox addon called memory fox leaving browser memory management on only.

Since then I have not had another BSOD.

It appears that on my system this addon and ESET 5 do not play well together.

The program can be found here.

Code:

http://www.browsermemory.com/

Anyone else have these exact issues?

 

Hello,

I have asked ESET's QA engineers to see if they can reproduce this issue.

Regards,

Aryeh Goretsky

 

Hello,

The QA engineer I spoke to was not able to reproduce the issue when testing Mozilla Firefox 8.01 with Memory Fox 7.4 under Microsoft Windows 7 SP1 (x86). If you have any additional information about how to reproduce the issue, please let me know and I shall relay it to the engineer.

Regards,

Aryeh Goretsky

 

This should be fixed in the next build of the HIPS module. Can you confirm the crashes go away after disabling HIPS for a while?