Eraser 6.0.6.1376: Appears to cause bluescreen on Win7 x64

[MacGyver]

As the topic name suggests, Eraser 6.0.6.1376 causes a bluescreen for me on Windows 7 Business 64 bit. WinDbg points the finger at Eraser.exe. Below is the output from WinDbg, the windows system debugger, run on a small memory dump from that stop error:


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


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02863000 PsLoadedModuleList = 0xfffff800`02aa0e50
Debug session time: Sun Jan 3 11:04:19.097 2010 (GMT+1)
System Uptime: 0 days 19:20:17.528
Loading Kernel Symbols
...............................................................
................................................................
.......................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 000007ff`fffdb018). Type ".hh dbgerr001" for details
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {3b9, 2, 0, fffff80002b166f5}

PEB is paged out (Peb.Ldr = 000007ff`fffdb018). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 000007ff`fffdb018). Type ".hh dbgerr001" for details
Probably caused by : ntkrnlmp.exe ( nt!ExQuerySystemLockInformation+175 )

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000000000003b9, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002b166f5, address which referenced memory

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

PEB is paged out (Peb.Ldr = 000007ff`fffdb018). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 000007ff`fffdb018). Type ".hh dbgerr001" for details

READ_ADDRESS: 00000000000003b9

CURRENT_IRQL: 2

FAULTING_IP:
nt!ExQuerySystemLockInformation+175
fffff800`02b166f5 488b80b8030000 mov rax,qword ptr [rax+3B8h]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: Eraser.exe

TRAP_FRAME: fffff8800b559600 -- (.trap 0xfffff8800b559600)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=fffffa8006490810
rdx=fffff88009406748 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002b166f5 rsp=fffff8800b559790 rbp=0000000000000000
r8=0000000000010000 r9=fffff80002a78770 r10=0000000000000002
r11=0000fffffffff000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt!ExQuerySystemLockInformation+0x175:
fffff800`02b166f5 488b80b8030000 mov rax,qword ptr [rax+3B8h] ds:0bef:03b9=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800028d4469 to fffff800028d4f00

STACK_TEXT:
fffff880`0b5594b8 fffff800`028d4469 : 00000000`0000000a 00000000`000003b9 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`0b5594c0 fffff800`028d30e0 : 00000000`00000001 00000000`0000d0e8 00000014`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`0b559600 fffff800`02b166f5 : 00000000`00000008 fffff880`0b559ca0 00000000`00000000 fffff800`02b474c9 : nt!KiPageFault+0x260
fffff880`0b559790 fffff800`02d34445 : fffff880`09406748 fffff800`00010000 00000000`00000000 fffff880`0b559880 : nt!ExQuerySystemLockInformation+0x175
fffff880`0b559800 fffff800`02c3758f : 00000000`00000000 00000000`1bf5eb40 fffff880`09406748 fffffa80`071728d0 : nt!ExpGetLockInformation+0x55
fffff880`0b559840 fffff800`02bd0e49 : 00000000`025d7748 00000000`025f4658 00000000`1bf5ec30 00000000`0000c5c0 : nt! ?? ::NNGAKEGL::`string'+0x5821f
fffff880`0b559be0 fffff800`028d4153 : 00000000`00000001 fffff880`0b559ca0 000007fe`f6838100 00000000`025f4658 : nt!NtQuerySystemInformation+0x4d
fffff880`0b559c20 00000000`7791021a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`1bf5ea78 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7791021a


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ExQuerySystemLockInformation+175
fffff800`02b166f5 488b80b8030000 mov rax,qword ptr [rax+3B8h]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!ExQuerySystemLockInformation+175

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600

FAILURE_BUCKET_ID: X64_0xA_nt!ExQuerySystemLockInformation+175

BUCKET_ID: X64_0xA_nt!ExQuerySystemLockInformation+175

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


I'm willing to give you any information you need to analyse the problem, but I'd rather not keep eraser on this machine: It has happened twice now, and I'd prefer it not to happen a third time.

 

[Joel]

It sounds like my suspicion for an earlier (unrelated) problem is true; while Eraser 5 used the same API calls to get entropy information Eraser 6 (written in .NET) cannot. I've got a private build which removes the dependencies on the particular call (NtQuerySystemInformation) if you are interested to test it, let me know (PM me with your email address).

 

[MacGyver]

I'm going to PM you my address in a minute, just one thing you should know: Eraser is not actively erasing when these bluescreens happen, rather, it's just sitting there in the systray. They only happened after the computer being on / eraser being running for about 15 hours. If it is indeed triggered by that particular call, why is Eraser trying to get entropy while being inactive? (I know, I could look at the code to find out, but I still wouldn't understand your reasoning, probably.) Just saying that this might not be related.

 

[Joel]

Eraser does gather entropy even when idle (to be exact, at every 10 minutes or so, if memory serves) so that when the PRNG is executed sufficient entropy is available for the erase procedure.

Thanks!

 

[jokerboy]

I can't even get eraser 6.0.6.1376 to work on my Windows 7 x64. I'm runing the ultimate version and after starting eraser, I get the UAC prompt. If I click yes, I get the "Eraser has stopped working" window.

 

[Joel]

There should not be any UAC prompts, Eraser doesn't have a manifest declaring administrator rights are required to run. Right-click on the Eraser icon, go to Properties, Compatibility, uncheck Always run with administrator privileges (at the bottom)

For your crash: have you checked http://bbs.heidi.ie/viewtopic.php?f=14&t=5843#p16110?

 

[jokerboy]

You were correct, I did have "run as admin" checked when I was trying to get it to run.

I have installed r1483, checked the "Default Erasure Methods..." plugin box and selected the defaults and it works now.

Thanks for your help!

 

[heckheck]

Is there an update on this bug. I am running into nearly the identical bugcheck signature on Windows 7 Ultra 64 with Eraser 6.0.6.1376 installed.

In the meantime will disabling the Eraser service likely prevent the crash, and will I still be able to use Eraser if I disable it (manually with a right click like I used to before the systray service was added)?

Thanks,

-Jim

 

[Joel]

Is there an update on this bug.

I believe it's fixed in trunk already, you can get a nightly 6.0 build to try. But the usual nightly/beta warnings apply.

and will I still be able to use Eraser if I disable it (manually with a right click like I used to before the systray service was added)?

No, it won't. It'll start when you need to do an erasure.

 

[MacGyver]

My apologies about my radio silence on this bug. The fix Joel provided me with (and I believe is also in trunk now?) works like a charm.

 

[heckheck]

I believe it's fixed in trunk already, you can get a nightly 6.0 build to try. But the usual nightly/beta warnings apply.

Joel

Thanks for the quick reply, and I'm glad it's fixed in trunk. Can you guess when the next stable build containing the fix might be released? I'd rather not beta test on this particular system and would rather wait for the official fix.

I had asked about disabling Eraser in the meantime, but my question was not worded well, and so I don't understand the context of your answer. I located under the 'startup' tab of msconfig.exe the Eraser startup item. Here are my three questions.

1. Will disabling the startup of Eraser under msconfig.exe prevent the crash I'm currently experiencing

2. Will Eraser still function (via right click) if the startup is disabled. Basically on demand as needed.

3. Will I avoid the crash if I then exit Eraser after use instead of letting it minimize to the system tray.

Thank you very much for your answers and help!

-Jim

 

[Joel]

Thanks for the quick reply, and I'm glad it's fixed in trunk. Can you guess when the next stable build containing the fix might be released? I'd rather not beta test on this particular system and would rather wait for the official fix.

I'm targeting March sometime (am trying to get a predictable release cycle) but there's always the probability of showstopping bugs.

1. Will disabling the startup of Eraser under msconfig.exe prevent the crash I'm currently experiencing

It'll not crash for as long as Eraser is not running, so indirectly, yes.

2. Will Eraser still function (via right click) if the startup is disabled. Basically on demand as needed.

Yes -- but Eraser will be started to run the erase, and during this time it may crash.

3. Will I avoid the crash if I then exit Eraser after use instead of letting it minimize to the system tray.

Same as 1 -- it'll only not crash when Eraser isn't running, but as soon as it starts, as in 2, it might.