Kept getting blue screens once in a while with the previous Sandboxie version, updated to the latest, and just got my first crash. Did not actually use Sandboxie for a very long time, it was sitting in the background. Not even sure why it was active? Does the "Trust No Program" apply to Sandboxie itself?

Sandboxie 3.50 64bit on Windows 7 64bit.

Ran it through the WinDbg, here's the results:



MODULE_NAME: SbieDrv

FAULTING_MODULE: fffff80002a59000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4cbb7bcf

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!strnicmp+32e4
fffff800`02a5e4e0 8a01 mov al,byte ptr [rcx]

CONTEXT: fffff8800d220640 -- (.cxr 0xfffff8800d220640)
rax=000007ffffff0000 rbx=fffff8800d221130 rcx=000007ffffff0000
rdx=0000000000000000 rsi=0000000000000004 rdi=0000000000000000
rip=fffff80002a5e4e0 rsp=fffff8800d221010 rbp=000000007540ab1c
r8=0000000000000000 r9=00000000754434f8 r10=fffff8800d221b68
r11=00000000753f0000 r12=000000007543baa4 r13=fffff8800d221100
r14=fffff8800bf8fcd0 r15=0000000075443400
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010282
nt!strnicmp+0x32e4:
fffff800`02a5e4e0 8a01 mov al,byte ptr [rcx] ds:002b:000007ff`ffff0000=??
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002d966ed to fffff80002a5e4e0

STACK_TEXT:
fffff880`0d221010 fffff800`02d966ed : fffff880`00000000 00000000`753f0000 fffff880`00000000 fffff880`00000000 : nt!strnicmp+0x32e4
fffff880`0d2210a0 fffff800`02aa6f01 : fffff900`00000000 fffff880`0bf8fe30 fffff900`00000001 fffff880`0d222000 : nt!NtSetInformationProcess+0x441d
fffff880`0d221640 fffff800`02aa60c7 : 00000000`00000000 00000000`00000000 fffff900`c0580bf8 fffff960`00151332 : nt!ExfTryToWakePushLock+0x879
fffff880`0d221750 fffff800`02ad0b9d : fffffa80`0e16e360 00000000`00000000 00000000`00000000 fffffa80`0e16e360 : nt!KeStackAttachProcess+0x1187
fffff880`0d2217d0 fffff800`02ad2cff : fffffa80`0e16e360 fffff880`03171180 fffffa80`00000000 00000000`00000000 : nt!KeAcquireSpinLockAtDpcLevel+0x9dd
fffff880`0d221860 fffff800`02aa80e4 : fffff900`c2751100 fffff960`00000005 fffffa80`09d43b00 00000000`00000000 : nt!KeWaitForMutexObject+0x19f
fffff880`0d221900 fffff800`02aa6101 : fffffa80`0e16e360 fffffa80`0e16e3b0 00000000`00000000 00000000`00000000 : nt!PsIsSystemProcess+0x94
fffff880`0d221940 fffff800`02aa6487 : fffffa80`0e16e360 00000000`00000000 fffff800`02aa8070 00000000`00000000 : nt!KeStackAttachProcess+0x11c1
fffff880`0d2219c0 fffff880`0a713fbe : fffffa80`0e16e360 fffff880`0a705053 00000000`7540ab1c fffff800`02ac8993 : nt!ObReferenceObjectByPointerWithTag+0x233
fffff880`0d221b50 fffff880`0a705053 : 00000000`7540ab1c fffff800`02ac8993 fffffa80`0e16e360 00000000`000de278 : SbieDrv+0xffbe
fffff880`0d221b60 00000000`7540ab1c : fffff800`02ac8993 fffffa80`0e16e360 00000000`000de278 fffff880`0d221b88 : SbieDrv+0x1053
fffff880`0d221b68 fffff800`02ac8993 : fffffa80`0e16e360 00000000`000de278 fffff880`0d221b88 00000000`00fb09b8 : 0x7540ab1c
fffff880`0d221b70 00000000`7542fcba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeSynchronizeExecution+0x3a43
00000000`000de208 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7542fcba


FOLLOWUP_IP:
SbieDrv+ffbe
fffff880`0a713fbe 55 push rbp

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: SbieDrv+ffbe

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: SbieDrv.sys

STACK_COMMAND: .cxr 0xfffff8800d220640 ; kb

BUCKET_ID: WRONG_SYMBOLS

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

Can you upload the dump file somewhere? I may be able to identify the problem by studying this post but if I could use the dump file directly it would certainly help.

To configure Windows to issue minidumps instead of full dumps, please see this

http://blog.nirsoft.net/2010/07/27/how-to-configure-windows-to-create-minidump-files-on-bsod/

The file is almost 900MB, plus it contains tons of my private information.
I have reconfigured Windows to create minidumps instead of kernel dumps on BSOD, so the next time it happens I will be able to send it to you.
Also, I have windows debugging tools, so if you want me to do anything with the kernel dump file, I would love to help.

Thanks!

Thanks. I'll be looking forward to the minidump. I did look briefly at the dump analysis you posted, but something is strange about it. It's as if it is missing a bunch of stack frames in the STACK_TEXT section. I'm not really sure that I can explain it. I hope the minidump can help here, and while you're experimenting, please upgrade to version 3.51.01, so your minidump will be issued against an up-to-date version of Sandboxie.

Could it be that not all symbols are loaded? Please send me the pdb file so i can get a better dump text. Also, the download page only lists the 3.50 (oct 18th) version, not 3.51.

Get it here: http://sandboxie.com/phpbb/viewtopic.php?t=9320

I'd rather not share the PDB files, and instead get the minidump from you.

As a side note, I don't think PDBs are as important for constructing stack backtrace on 64-bit Windows as they are on 32-bit Windows. I believe they designed stack frames much more strictly in 64-bit, to solve the mess that developed with 32-bit code. Not sure though, I could be wrong.

I got your minidump, thanks. It still looks strange. I know the Sandboxie driver is mentioned in the stack trace but it seems like an APC interrupt has taken control away from Sandboxie code, and during processing of that APC, that's when the crash occurrs.

Since you started seeing these BSODs, did you at any time uninstall Sandboxie, to see if you still get BSODs without Sandboxie installed?

No, haven't, but all crash dumps point to sandboxie as a culprit .

I will uninstall it and let you know. Usually it happens about once or twice a week, so will know in a week or so.

I realize Sandboxie is named in the stack trace but again it's not clear:



As you can see, SbieDrv got to execute just 0x20-0x30 bytes in a couple of places (Entry1 and Entry2) and then there was delivery of an APC and control went somewhere else, unrelated to Sandboxie.

Of course if the crashes continue even with Sandboxie out of the way, I'm not sure how you would be able to identify the cause of the crash, considering it seems to actually occur in the Windows kernel, at some undocumented location.

It is strange. I sent you a few more minidumps from my previous crashes, could you take a look if they occur at the same place? Could it be that sandboxie is putting kernel into some unstable mode so that an APC interrupt causes major problem? Or do you think the stack is corrupted somehow?

These additional three minidumps look like they have nothing to do with Sandboxie, but exactly like the BSOD reported in this discussion here --

http://www.minecraftforum.net/viewtopic.php?f=17&t=48721

They match on the bugcheck - SYSTEM_SERVICE_EXCEPTION (3b)
they match on the faulting IP - nt! ?? ::FNODOBFM::`string'+c186
and they even match on the process name - devenv.exe.

So I suggest you take the advice from that other discussion and "[install] the recommended graphic driver version instead of NVidia's lastest". Unfortunately it doesn't say what exactly is that "recommended" graphic driver.

Same thing happens to me on Sandboxie v3.48 with Windows 7 (64bit). The stack trace is a little difference though and it might have something to do with devenv.exe (MS Visual Studio 2010) ??



Minidump: http://www.mediafire.com/?9638t94wel6iimq

Thanks!

As I said in my earlier comment in this topic, I don't believe Sandboxie is causing this problem.