BugCheck 3B, c0000005

OSR_Community_User · January 29, 2013, 7:29pm

Hi people,

I have a serious problem with the above bugcheck - BugCheck 3B, {c0000005, fffff800034151c4, fffff8800c6453f0, 0}.
It is being caused by my own application which I am developing on the following system:
Windows 7 Pro x64 SP1 - 8GB Ram - 300GB SSD with 109GB system partition (20.7GB free).
Here is a full MEMOMRY.DMP file (https://skydrive.live.com/redir?resid=837FE7B0AF7A78B8!158&authkey=!AAjagX7P_On7RNA).

What I have done till now is this:

Checked my memory modules with memtest.
played around with the debugging tools for windows which show the obvious ********** Excessive NonPaged Pool Usage *****.
monitored my application with process explorer but could not see anything obvious to my eyes.

It is obvious that my app is to blame (PROCESS_NAME: BBAnalyzer)
A few words on what it does: It is a recursive process where the first instance of an object called ‘bbVirtualUser’ calls one or more new instances of itself. Some instances reach a stage where they may be destroyed (most are), while others remain. The first instance controls how many instances are running at the same time and tries to keep this number low. The instances are launched as separate threads like so:
t.IsBackground = True
t.SetApartmentState(ApartmentState.STA)
t.Start()

Development is carried out in Microsoft Visual Basic 2012 (vs 2012 update 1) (.net 4.5).

I hope I have given enough information. If I have left anything out please let me know.
I have spent about a week on this (inc. 1 full day uploading the dump!) but it is beyond my expertise.
I appreciate in advance all the help you can give me in resolving this because development is impossible with all the crashing!
I read somewhere that it may be possible to dig deep within the dump file and discover what was the actual call that caused the crash.

Kind Regards
Rory

OSR_Community_User · January 29, 2013, 7:43pm

Have you run your same app without SandBoxie installed?

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

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff800034151c4, Address of the instruction which caused the bugcheck
Arg3: fffff8800c6453f0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

“KERNEL32.dll” was not found in the image list.
Debugger will attempt to load “KERNEL32.dll” at given base 00000000`00000000.

Please provide the full image name, including the extension (i.e. kernel32.dll)
for more reliable results.Base address and size overrides can be given as
.reload <image.ext>=,.
Unable to add module at 0000000000000000 EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. FAULTING_IP: nt! ?? ::FNODOBFM::string’+c061
fffff800034151c4 8a01 mov al,byte ptr [rcx] CONTEXT: fffff8800c6453f0 -- (.cxr 0xfffff8800c6453f0) rax=000007ffffff0000 rbx=fffff8800c645ef0 rcx=000007ffffff0000 rdx=0000000000000000 rsi=0000000000000004 rdi=0000000000000000 rip=fffff800034151c4 rsp=fffff8800c645dd0 rbp=00000000734dad7c r8=0000000000000000 r9=00000000735134f8 r10=fffff8800c646a68 r11=00000000734c0000 r12=000000007350bc90 r13=fffff8800c645ec0 r14=fffff8800f114bd0 r15=0000000073513400 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! ?? ::FNODOBFM::string’+0xc061:
fffff800034151c4 8a01 mov al,byte ptr [rcx] ds:002b:000007ffffff0000=??
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: BBAnalyzer.vsh

CURRENT_IRQL: 1

MANAGED_STACK: !dumpstack -EE
No export dumpstack found

LAST_CONTROL_TRANSFER: from fffff80003779d55 to fffff800034151c4

STACK_TEXT:
fffff8800c645dd0 fffff80003779d55 : fffff88000000000 00000000734c0000 fffff88000000000 fffff88000000000 : nt! ?? ::FNODOBFM::string'+0xc061 fffff8800c645e60 fffff8000347e561 : 0000000000000000 fffff8800f114d30 0000000000000000 fffff8800c647000 : nt!PspGetSetContextInternal+0x265 fffff8800c646400 fffff8000347fa37 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!PspGetSetContextSpecialApc+0xa1 fffff8800c646510 fffff8000347fce7 : 0000000000000000 0000000000000000 0000000000000000 fffffa8011e3f060 : nt!KiDeliverApc+0x1c7 fffff8800c646590 fffff80003494188 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiApcInterrupt+0xd7 fffff8800c646720 fffff8000347edf4 : fffff8800c646800 fffffa8000000005 fffffa800b8cb300 fffffa8000000000 : nt!KeWaitForSingleObject+0x599 fffff8800c6467c0 fffff8000347fa71 : fffffa8011e3f060 fffffa8011e3f0b0 0000000000000000 0000000000000000 : nt!KiSuspendThread+0x54 fffff8800c646800 fffff8000347fce7 : 0000000000000000 0000000000000000 fffff8000347eda0 0000000000000000 : nt!KiDeliverApc+0x201 fffff8800c646880 fffff880041db749 : 0000000000002f08 00000000734b2450 0000000000000000 0000000000000000 : nt!KiApcInterrupt+0xd7 fffff8800c646a10 fffff880041ce053 : 00000000734dad7c fffff8000348c253 fffffa8011e3f060 000000000f94e108 : SbieDrv+0xe749 fffff8800c646a60 00000000734dad7b : fffff8000348c253 fffffa8011e3f060 000000000f94e108 fffff8800c646a88 : SbieDrv+0x1053 fffff8800c646a68 fffff8000348c253 : fffffa8011e3f060 000000000f94e108 fffff8800c646a88 00000000002b1782 : wow64win!whNtUserGetThreadState+0x17 fffff8800c646a70 00000000734b2e09 : 00000000734b2dbf 00000000694b45ad 0000000000000023 0000000000000246 : nt!KiSystemServiceCopyEnd+0x13 000000000f94ea18 00000000734b2dbf : 00000000694b45ad 0000000000000023 0000000000000246 000000001f38edc0 : wow64cpu!CpupSyscallStub+0x9 000000000f94ea20 000000007352d07e : 0000000000000000 00000000734b1920 0000000000000000 0000000000000000 : wow64cpu!Thunk0Arg+0x5 000000000f94eae0 000000007352c549 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : wow64!RunCpuSimulation+0xa 000000000f94eb30 000000007782e707 : 0000000000000000 000000007efdf000 000000007eef4000 0000000000000000 : wow64!Wow64LdrpInitialize+0x429 000000000f94f080 00000000777dc32e : 000000000f94f140 0000000000000000 000000007efdf000 0000000000000000 : ntdll! ?? ::FNODOBFM::string’+0x29364
000000000f94f0f0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!LdrInitializeThunk+0xe

FOLLOWUP_IP:
SbieDrv+e749
fffff880`041db749 488bc3 mov rax,rbx

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: SbieDrv+e749

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: SbieDrv

IMAGE_NAME: SbieDrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4c305969

STACK_COMMAND: .cxr 0xfffff8800c6453f0 ; kb

FAILURE_BUCKET_ID: X64_0x3B_SbieDrv+e749

BUCKET_ID: X64_0x3B_SbieDrv+e749

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

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Tuesday, January 29, 2013 4:28 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BugCheck 3B, c0000005

Hi people,

I have a serious problem with the above bugcheck - BugCheck 3B, {c0000005, fffff800034151c4, fffff8800c6453f0, 0}.
It is being caused by my own application which I am developing on the following system:
Windows 7 Pro x64 SP1 - 8GB Ram - 300GB SSD with 109GB system partition (20.7GB free).
Here is a full MEMOMRY.DMP file (https://skydrive.live.com/redir?resid=837FE7B0AF7A78B8!158&authkey=!AAjagX7P_On7RNA).

What I have done till now is this:
1. Checked my memory modules with memtest.
2. played around with the debugging tools for windows which show the obvious *****Excessive NonPaged Pool Usage.
3. monitored my application with process explorer but could not see anything obvious to my eyes.

It is obvious that my app is to blame (PROCESS_NAME: BBAnalyzer)
A few words on what it does: It is a recursive process where the first instance of an object called ‘bbVirtualUser’ calls one or more new instances of itself. Some instances reach a stage where they may be destroyed (most are), while others remain. The first instance controls how many instances are running at the same time and tries to keep this number low. The instances are launched as separate threads like so:
t.IsBackground = True
t.SetApartmentState(ApartmentState.STA)
t.Start()

Development is carried out in Microsoft Visual Basic 2012 (vs 2012 update 1) (.net 4.5).

I hope I have given enough information. If I have left anything out please let me know.
I have spent about a week on this (inc. 1 full day uploading the dump!) but it is beyond my expertise.
I appreciate in advance all the help you can give me in resolving this because development is impossible with all the crashing!
I read somewhere that it may be possible to dig deep within the dump file and discover what was the actual call that caused the crash.

Kind Regards
Rory

—
NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</image.ext>

OSR_Community_User · January 29, 2013, 8:06pm

No I haven’t.
Since I started developing the app back in October I have been testing it with everything on the machine running as normal.
If you want I can run some tests without sandboxie, but that will have to be done in 10-12 hours from now.

Daniel_Terhell · January 29, 2013, 11:49pm

>It is obvious that my app is to blame (PROCESS_NAME: BBAnalyzer)

No, if you are just running an app without a kernel driver, the system is
not supposed to bugcheck. Your app is provoking a bugcheck in a misbehaving
driver, that doesn’t mean your app is to blame. As it appears from the
output, the problem is the sbiedrv.sys driver. I suggest you contact their
support and send your dump file to them.

//Daniel

OSR_Community_User · January 30, 2013, 7:20am

I have just now disabled the sandboxie service and restarted the machine. SbieDrv.sys does not appear anywhere in process explorer.
I run my application about 3 minutes ago and I will leave it running for as long as possible.
I will let you know what happens.

OSR_Community_User · January 30, 2013, 4:16pm

Thanks Kenny and Daniel.
I have been running my app since morning today and has been running happily without a single blue screen, after disabling the sandboxie service.
I would never have thought that it was the culprit.
What made you think that it was not my own application causing the bugcheck?
Why do you think this is actually happening?

Tim_Roberts · January 30, 2013, 5:26pm

xxxxx@hotmail.com wrote:

I have been running my app since morning today and has been running happily without a single blue screen, after disabling the sandboxie service.
I would never have thought that it was the culprit.
What made you think that it was not my own application causing the bugcheck?

Applications don’t cause bugchecks. When an application fails, the
application dies but the system keeps on running. A bugcheck is caused
by an inconsistency in the kernel, which requires the participation of a
kernel driver.

Why do you think this is actually happening?

A bug in the Sandboxie driver.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

OSR_Community_User · January 30, 2013, 5:45pm

As has been said, applications don’t cause bugchecks. You had the info you needed the entire time in your debug output from !analyze -v:

Probably caused by : SbieDrv.sys ( SbieDrv+e749 )
fffff8800c646a10 fffff880041ce053 : 00000000734dad7c fffff8000348c253 fffffa8011e3f060 000000000f94e108 : SbieDrv+0xe749
fffff8800c646a60 00000000734dad7b : fffff8000348c253 fffffa8011e3f060 000000000f94e108 fffff8800c646a88 : SbieDrv+0x1053

FOLLOWUP_IP:
SbieDrv+e749
fffff880`041db749 488bc3 mov rax,rbx

MODULE_NAME: SbieDrv
IMAGE_NAME: SbieDrv.sys
FAILURE_BUCKET_ID: X64_0x3B_SbieDrv+e749
BUCKET_ID: X64_0x3B_SbieDrv+e749

Then I did what every self-respecting developer would do … I googled “SbieDrv” and found SandBoxie …

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, January 30, 2013 1:16 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BugCheck 3B, c0000005

Thanks Kenny and Daniel.
I have been running my app since morning today and has been running happily without a single blue screen, after disabling the sandboxie service.
I would never have thought that it was the culprit.
What made you think that it was not my own application causing the bugcheck?
Why do you think this is actually happening?

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · January 30, 2013, 7:44pm

I knew sandboxie was mentioned in the report. I just thought that my app somehow was to blame for corrupting memory space occupied by sandboxie.

I still do not understand why sandboxie has anything to do with this issue. I never asked sandboxie to do anything in conjunction with my app. And I do not understand why it only happens with my app and not with anything else on my system since I set it up in 2011.

Anyhow. I will send them my report. It may help them more than myself in the end!

If you have any more light to shed please do so, otherwise you can close the thread.
Thanks again to all of you that spent time on this.

OSR_Community_User · January 30, 2013, 8:19pm

Your app is running in own virtual memory space and has no way how to directly corrupt Sandboxie memory space. It seems as they trap some OS services (system wide) and have a bug in their code. The bug probably manifests itself only under some circumstances and you were lucky enough to write an app which caused them. Anyway, it is NOT your fault. The problem is on their side with no doubt. The best what you can do is to send them report and memory dump as you plan. Based on their response you can make decision if you should continue using their software (thanks + bugfix) or remove it from your system (ignorance, denial etc.).

Michal

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-525209-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, January 31, 2013 1:44 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BugCheck 3B, c0000005

I knew sandboxie was mentioned in the report. I just thought that my app
somehow was to blame for corrupting memory space occupied by sandboxie.

I still do not understand why sandboxie has anything to do with this issue. I
never asked sandboxie to do anything in conjunction with my app. And I do not
understand why it only happens with my app and not with anything else on my
system since I set it up in 2011.

Anyhow. I will send them my report. It may help them more than myself in the
end!

If you have any more light to shed please do so, otherwise you can close the
thread.
Thanks again to all of you that spent time on this.

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

OSR_Community_User · January 30, 2013, 8:50pm

Thanks Michal. I am so releived it is not a bug in my app!

Maxim_S_Shatskih · January 31, 2013, 8:43am

> It is obvious that my app is to blame (PROCESS_NAME: BBAnalyzer)

No.

The app, even the most buggy app, cannot crash a kernel.

You have a buggy kernel module, or buggy hardware.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim_S_Shatskih · January 31, 2013, 8:47am

> I knew sandboxie was mentioned in the report. I just thought that my app somehow was to blame for

corrupting memory space occupied by sandboxie.

Reading some good book on modern OS’s general architecture (either Windows or Linux, some general principles are the same) will help you a lot.

“memory space occupied by sandboxie” is implemented in a way that no apps can corrupt it.

I still do not understand why sandboxie has anything to do with this issue.

It crashes. It’s their issue, not yours.

I never asked sandboxie to do anything in conjunction with my app.

So what? if sandboxie filters some stuff in the kernel, then the filtering path can have a bug.

And I do not understand why it only happens with my app

By mere luck. Probably because your app starts lots of threads, and sandboxie (is this some moronic “security software” discussed in a neighbouring thread?) filters the thread creation path.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com