[SOLVED] BSOD while installing ZoneAlarm - Windows 7 x86

D

Docfxit

Contributor
Joined
Feb 22, 2015
Posts
248
This BSOD happens when I attempt to install ZoneAlarm. ZoneAlarm never does get installed.
I had to uninstall ZoneAlarm in Safe Mode in order to boot into normal mode.
ZoneAlarm Pro ver. 134.261.000 Firewall with no Antivirus
I have contacted ZoneAlarm. They say there is nothing wrong with ZA

· OS - Windows 7
· x86 32-bit
· What was original installed OS on system?
Windows 7 Ultimate 32bit
· The OS retail version
· Age of system (hardware)
New
· Age of OS installation - have you re-installed the OS?
Old. The hard drive came from a different laptop with the OS installed.

· CPU
Intel Core i7-5600U 2.60 GHz
· Video Card
NVIDIA Quadro K620M
· MotherBoard - (if NOT a laptop)
Laptop
· Power Supply - brand & wattage (if laptop, skip this one)
Laptop
· System Manufacturer
Lenovo
· Exact model number (if laptop, check label on bottom)
20E2CTO1WW
· Laptop or Desktop?
Laptop

Thank you for looking at this,

Docfxit
 

Attachments

This BSOD happens when I attempt to install ZoneAlarm
Click to expand...

Here's your first problem.

In all seriousness, ZA is notoriously a poorly developed program. The last time I genuinely remember using this software was back when I was a teenager, and used it to poison IP's on Xbox Live.

Code: 
0: kd> .bugcheck
Bugcheck code 000000C4
Arguments 000000f6 00000244 8ed0ad40 91e72207

Without a kernel-dump, we can't look into it in-depth, but the reason for the crash was a reference to a user handle as kernel-mode.

Code: 
0: kd> knL
 # ChildEBP RetAddr  
00 ccfb3634 83178f03 nt!KeBugCheckEx+0x1e
01 ccfb3654 8317d766 nt!VerifierBugCheckIfAppropriate+0x30
02 ccfb36e8 8306426b nt!VfCheckUserHandle+0x14f
03 ccfb371c 83064125 nt!ObReferenceObjectByHandleWithTag+0x13b
04 ccfb3740 83067962 nt!ObReferenceObjectByHandle+0x21
05 ccfb37ac 830781f3 nt!ObpLookupObjectName+0x90
06 ccfb3808 83043a83 nt!ObOpenObjectByName+0x165
07 ccfb38e8 83043eca nt!CmCreateKey+0x2b2
08 ccfb3910 91e72207 nt!NtCreateKey+0x1f
09 ccfb3a30 82e7e896 vsdatant+0x47207
0a ccfb3a30 82e7c37d nt!KiSystemServicePostCall
0b ccfb3ac4 83186fdd nt!ZwCreateKey+0x11
0c ccfb3af0 91e7436b nt!VfZwCreateKey+0x4e
0d ccfb3bf4 91e7465e vsdatant+0x4936b
0e ccfb3c24 82e7e896 vsdatant+0x4965e
0f ccfb3c24 779770f4 nt!KiSystemServicePostCall
10 000af540 00000000 0x779770f4

ZoneAlarm's TrueVector driver calls the ZwCreateKey function to presumably create a new registry key for itself since this is a bug check during its installation. We can see the issue right away as far as I know, which is the fact that it's using the *Zw kernel prefix function, as opposed to the *Nt user one.

This is why when we get to providing access validiation on the object handle that was supplied by the CreateKey function, verifier checks the integrity of the handle and it bug checks as it notices its mistake.

So this is indeed ZoneAlarm's problem.
 
Thank you very much for looking into this. And for doing it so fast.

It's obviously not a problem for millions of other computers.
What's different about this computer?
Is it a BIOS setting of some sort? (Which I highly doubt)
Is it another driver?
According to what you said it seems like it's a programing problem in TrueVector.
Why can millions of other computers create this *Zw kernel prefix function and this computer can't?

It appears there are no dumps in C:\Windows\Minidump
Would it help if I could create a kernel-dump for you? How?

Do you know of a better software firewall that can be run on the same machine as I'm trying to protect?

Thank you,

Docfxit
 
It's obviously not a problem for millions of other computers.
Click to expand...

Can we genuinely confirm that though? No we can't.

https://www.google.com/?gws_rd=ssl#q=zonealarm+vsdatant+site:www.zonealarm.com

Would it help if I could create a kernel-dump for you? How?
Click to expand...

Yeah, but it won't fix the problem. It'll help me help them figure out what's wrong. This is a driver bug on their end, whether they deny it or not.

https://msdn.microsoft.com/en-us/li...953(v=vs.85).aspx?f=255&MSPPError=-2147217396

Check and see if there's a MEMORY.DMP in your C:\Windows folder, is there? If not, follow the above link as that's how to enable a kernel-dump.

Do you know of a better software firewall that can be run on the same machine as I'm trying to protect?
Click to expand...

No, sorry. I don't use any. Most firewall software I'd use is the ones that come with antivirus suites, the rest are pretty terrible - i.e Sunbelt, etc.
 
I had selected for Write debugging information - small memory dump. How could I change it to get a memory dump for you?

If you did determine the coding error from the dump maybe they would be much more likely to fix it.
They obviously don't have the talent to fix it themselves.

It would be great if you could look into it so I could pass the information to them.

Thank you,

Docfxit
 
I had selected for Write debugging information - small memory dump. How could I change it to get a memory dump for you?
Click to expand...

Change from Small > Kernel.

Keep verifier enabled and let it crash again by installing it like you were before. After it crashes, upload the MEMORY.DMP in your C:\Windows folder to a website of your choice (Onedrive for example), and paste the link to it here.
 
I have no idea what happened.
I started verifier according to the instructions at sysnative.com once again.
I prepared the system to install the same version of ZoneAlarm.
I installed ZoneAlarm.
I got a BSOD for BDSELFPR.SYS this time. I didn't get a BSOD for ZoneAlarm. ZoneAlarm did complete the install this time.
I had run the same programs, same versions many times before.
The only thing I can think of is that it could be I may have turned on verifier before installing Bitdefender last time.

I wonder if I didn't get the BSOD on ZoneAlarm because it wasn't installed before I turned on verifier. After I post this I will rerun verifier since ZoneAlarm is currently installed.

I have attached the BSOD of BDSELFPR.SYS to see if you can shed any light on this one.

Thank you very much for looking into this for me.

Docfxit
 

Attachments

Okay, wait. I'm confused now.

Why are you trying to install ZoneAlarm with an antivirus already installed (Bitdefender)? Bitdefender uses a WFP firewall, therefore there's no need to install another one, especially one much worse. That's why you're crashing when you attempt to install ZoneAlarm.
 
The Bitdefender I have installed is only an Anti-virus. Not a firewall. I know I could get Bitdefender with a firewall. I don't like the firewall they provide.

Bitdefender Anti-virus only.
ZoneAlarm Firewall only.

Thanks,

Docfxit
 
Neat, had no idea you could get it W/O firewall.

Anyway, what you provided isn't a kernel dump. Remember, MEMORY.DMP in your C:\Windows folder, not C:\Windows\Minidump.
 
Could you upload it to a different site, such as Onedrive?
The download speed from that server is appalling, it's downloading it a few kb/s and it's over 100mb.
 
Thank you immensely,
I have had a BSOD with Bitdefender before. Not very often but it would be really great to get them some information to fix it.

Docfxit
 
Okay, so after some investigation and discussion with others, this is likely to be a problem caused by Bitdefender - not ZoneAlarm.

The dump is missing a lot of data, so it's not a 100% surefire answer, but probably as close as we're going to get.

Code: 
2: kd> knL
 # ChildEBP RetAddr  
00 e1d5c124 83f58f03 nt!KeBugCheckEx+0x1e
01 e1d5c144 83f5d766 nt!VerifierBugCheckIfAppropriate+0x30
02 e1d5c1d8 83e64c37 nt!VfCheckUserHandle+0x14f
03 e1d5c1ec 8eea7cc3 nt!NtClose+0x45
WARNING: Stack unwind information not available. Following frames may be wrong.
04 e1d5c21c 83c59a66 bdselfpr+0x9cc3
05 e1d5c21c 83c573b9 nt!KiSystemServicePostCall
06 e1d5c298 bd78ca1f nt!ZwClose+0x11
07 e1d5c4cc bd792e47 vsdatant+0x4fa1f
08 e1d5c620 bd793234 vsdatant+0x55e47
09 e1d5c670 bd7933c9 vsdatant+0x56234
0a e1d5c6b4 bd793524 vsdatant+0x563c9
0b e1d5c6ec bd794033 vsdatant+0x56524
0c e1d5c814 bd7547db vsdatant+0x57033
0d e1d5c848 bd75494d vsdatant+0x177db
0e e1d5c860 bd75b6bb vsdatant+0x1794d
0f e1d5c9ac bd75b8ae vsdatant+0x1e6bb
10 e1d5c9e8 bd759d7f vsdatant+0x1e8ae
11 e1d5ca0c bd75a5ce vsdatant+0x1cd7f
12 e1d5ca44 bd758469 vsdatant+0x1d5ce
13 e1d5ca58 83f536c3 vsdatant+0x1b469
14 e1d5ca7c 83c52d44 nt!IovCallDriver+0x258
15 e1d5ca90 83e4a13b nt!IofCallDriver+0x1b
16 e1d5cab0 83e4d324 nt!IopSynchronousServiceTail+0x1f8
17 e1d5cb4c 83e94425 nt!IopXxxControlFile+0x6aa
18 e1d5cb80 8eea6ef2 nt!NtDeviceIoControlFile+0x2a
19 e1d5cc04 83c59a66 bdselfpr+0x8ef2
1a e1d5cc04 77a270f4 nt!KiSystemServicePostCall
1b 001be808 00000000 0x77a270f4

It looks like a handle that was visible in user-mode was accessed in kernel-mode. ZoneAlarm's firewall driver calls the nt!ZwClose function, and given it was called directly with the *Zw prefix, the bug check by verifier was thrown as it's a user-handle calling a kernel prefixed function from a user-handle.

Right away with this being known, we may jump to say "ZoneAlarm is the issue", which I did. If we investigate a bit deeper however...

If we look at the handle:

Code: 
2: kd> !handle 300

PROCESS 95bf14e8  SessionId: 1  Cid: 07bc    Peb: 7ffde000  ParentCid: 1ffc
    DirBase: 9f02c280  ObjectTable: c44f85d8  HandleCount: 192.
    Image: vsmon.exe

Handle table at c44f85d8 with 192 entries in use

0300: Object: c9dd6220  GrantedAccess: 00020019 Entry: db2ba600
Object: c9dd6220  Type: (869e4980) Key
    ObjectHeader: c9dd6208 (new version)
        HandleCount: 1  PointerCount: 1
        Directory Object: 00000000  Name: \REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\PROFILELIST\S-1-5-18

Code: 
2: kd> dt nt!_MODE c9dd6208
1 ( UserMode )

It was a user-mode handle, so what's up here?

Code: 
2: kd> .bugcheck
Bugcheck code 000000C4
Arguments 000000f6 00000300 95bf14e8 8eea7cc3

The 4th argument holds the driver that performed the incorrect reference.

Code: 
2: kd> !address 8eea7cc3

Usage:                  Module
Base Address:           8ee9e000
End Address:            8eebd000
Region Size:            0001f000
VA Type:                DriverImages
Module name:            bdselfpr.sys
Module path:            [\??\C:\Programs\Bitdefender\Bitdefender 2015\bdselfpr.sys]

It's Bitdefender's self protection driver, not anything related to ZoneAlarm.

Code: 
2: kd> !thread 95a1c7c8
THREAD 95a1c7c8  Cid 06b8.07d0  Teb: 7ffd5000 Win32Thread: 00000000 WAIT: (WrQueue) UserMode Non-Alertable
    95a37040  QueueObject
IRP List:
    89326ac0: (0006,0100) Flags: 00060800  Mdl: 00000000
Not impersonating
DeviceMap                 88008e08
Owning Process            93972d28       Image:         svchost.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      35856          Ticks: 2281 (0:00:00:35.583)
Context Switch Count      487            IdealProcessor: 1             
UserTime                  00:00:00.000
KernelTime                00:00:00.015
Win32 Start Address 0x71c935b1
Stack Init b89d7ed0 Current b89d7490 Base b89d8000 Limit b89d5000 Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

ChildEBP RetAddr  Args to Child              
b89d74a8 83c9a86d 95a1c7c8 8953a308 89537120 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
b89d74e0 83c996cb 95a1c888 95a1c7c8 95a37040 nt!KiSwapThread+0x266
b89d7508 83c9a3bd 95a1c7c8 95a1c888 00000000 nt!KiCommitThreadWait+0x1df
b89d7568 83cb423f 95a37040 00000001 00000000 nt!KeRemoveQueueEx+0x4f8
b89d7588 8ee1a857 95a37040 00000001 00000000 nt!KeRemoveQueue+0x1b
b89d75d4 8ee49b6f 95a37008 b89d7608 b89d7614 csc!UpCallRemoveQueueRequest+0x32 (FPO: [Non-Fpo])
b89d7618 8ee41746 8cf987d8 93972d28 00000000 csc!CscDclpCreateUpcallItemChangeNotificationInformation+0xa9c (FPO: [Non-Fpo])
b89d76ac 8ee3f61b 8cf987d8 00000001 00000020 csc!CscDclInternalFsControl+0x93b (FPO: [Non-Fpo])
b89d76e4 8eb885a4 00f987d8 89326b78 8cf98b30 csc!CscFsCtl+0x119 (FPO: [Non-Fpo])
b89d7704 8eb89156 00f987d8 89326ac0 b5218c90 rdbss!RxLowIoSubmit+0x24c (FPO: [Non-Fpo])
b89d772c 8eb89917 8cf987d8 89326ac0 b5218c90 rdbss!RxLowIoFsCtlShell+0x18b (FPO: [Non-Fpo])
b89d7800 8eb6cefc 8cf987d8 89326ac0 362aac7f rdbss!RxCommonFileSystemControl+0x229 (FPO: [Non-Fpo])
b89d7888 8eb832c9 8eb7d240 89326ac0 95a1a7c8 rdbss!RxFsdCommonDispatch+0x646 (FPO: [Non-Fpo])
b89d78b8 8ee3fbb2 8cf9c020 0d326ac0 8cc4c140 rdbss!RxFsdDispatch+0x1ab (FPO: [Non-Fpo])
b89d78e4 83f536c3 8cf9c020 00000000 89326b94 csc!CscFsdDispatch+0x29e (FPO: [Non-Fpo])
b89d7908 83c52d44 00000000 89326bb8 8cf9c020 nt!IovCallDriver+0x258
b89d791c 8ee155ff 892028e8 89202878 b531bb18 nt!IofCallDriver+0x1b
b89d7984 871f40fb 892028e8 00000103 89202878 csc!CscSurrogatePreProcess+0x5fa (FPO: [Non-Fpo])
b89d79a4 871f4b68 01202878 00000000 89326ac0 mup!MupCallSurrogatePrePost+0xf6 (FPO: [Non-Fpo])
b89d79bc 871f4551 89202878 8ce134e0 89326ac0 mup!MupStateMachine+0xb1 (FPO: [Non-Fpo])
b89d79d8 83f536c3 8c7acf08 89202878 00000000 mup!MupFsControl+0x77 (FPO: [Non-Fpo])
b89d79fc 83c52d44 00000000 89326ac0 8c7acf08 nt!IovCallDriver+0x258
b89d7a10 84d3520c 8c7ac878 89326ac0 00000000 nt!IofCallDriver+0x1b
b89d7a34 84d48ce8 b89d7a54 8c7ac878 00000000 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa (FPO: [Non-Fpo])
b89d7a6c 83f536c3 8c7ac878 89326ac0 95a1a7c8 FLTMGR!FltpFsControl+0xe8 (FPO: [Non-Fpo])
b89d7a90 83c52d44 00000000 89326ac0 8c7ac878 nt!IovCallDriver+0x258
b89d7aa4 83e4a13b 95a1a7c8 89326ac0 89326b9c nt!IofCallDriver+0x1b
b89d7ac4 83e4d324 8c7ac878 95a1a7c8 00000001 nt!IopSynchronousServiceTail+0x1f8
b89d7b60 83e760ff 8c7ac878 89326ac0 00000000 nt!IopXxxControlFile+0x6aa
b89d7b94 8eea7075 000002bc 00000754 00000000 nt!NtFsControlFile+0x2a
WARNING: Stack unwind information not available. Following frames may be wrong.
b89d7c04 83c59a66 000002bc 00000754 00000000 bdselfpr+0x9075
b89d7c04 77a270f4 000002bc 00000754 00000000 nt!KiSystemServicePostCall (FPO: [0,3] TrapFrame @ b89d7c34)
00fdfb8c 00000000 00000000 00000000 00000000 0x77a270f4

Let's look at the IRP:

Code: 
2: kd> !irp 89326ac0
Irp is active with 4 stacks 3 is current (= 0x89326b78)
 No Mdl: No System Buffer: Thread 95a1c7c8:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
>[  d, 0]   1 e1 8cf9c020 95a1a7c8 8ee1f927-b89d7930 Success Error Cancel pending
           \Driver\CSC    csc!CscSurrogateCompletionRoutine
            Args: 00000014 00000020 000901af 00fdfbbc
 [  d, 0]   1  0 8c7acf08 95a1a7c8 00000000-00000000    
           \FileSystem\Mup
            Args: 00000014 00000020 000901af 00fdfbbc

Now let's get information on the FILE_OBJECT structure:

Code: 
2: kd> !fileobj 95a1a7c8 


\.\.


Device Object: 0x8c7acf08   \FileSystem\Mup
Vpb is NULL
Access: Read SharedRead SharedWrite SharedDelete 


Flags:  0x40000
    Handle Created


FsContext: 0xb5218c90    FsContext2: 0xb5218f28
CurrentByteOffset: 0
Cache Data:
  Section Object Pointers: 95a18c7c
  Shared Cache Map: 00000000

Hmm, the Bitdefender filter driver seems to be up to no good.

Code: 
e1d5cb88          void * FileHandle = 0x00000220
e1d5cb8c          void * Event = 0x00000000
e1d5cb90          <function> * ApcRoutine = 0x00000000
e1d5cb94          void * ApcContext = 0x00000000
e1d5cb98          struct _IO_STATUS_BLOCK * IoStatusBlock = 0x001be7e8
e1d5cb9c          unsigned long IoControlCode = 0x8400009b
e1d5cba0          void * InputBuffer = 0x001be86c
e1d5cba4          unsigned long InputBufferLength = 0x20
e1d5cba8          void * OutputBuffer = 0x001be86c
e1d5cbac          unsigned long OutputBufferLength = 0x20

Bug check stack shows 0x8400009b - ERROR_TOO_MANY_TCBS, which implies another thread cannot be created. Possibly a symptom of the blockage on the Bitdefender filter driver.

Overall, I'd get rid of Bitdefender if you've had issues in the past, which I know for a fact you've had.
 
This is really great to hear. Super work for you to figure this out.

Would it be ok if I share this info with Bitdefender?

That is really really great of you to do this for me. (And I'm hoping for a lot of people) (If they will fix it)

Thank you so so much,

Docfxit
 
Would it be ok if I share this info with Bitdefender?
Click to expand...

If you'd like, but I am unfortunately unsure as to if it'll help as there's not much information. They're probably going to ask for a complete dump, and may or may not investigate it. If I had a complete dump I'd investigate it, but that would be a very large file and I am unsure if you'd like to provide such.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top