Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 5 subscribers
  • Views 10227 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

BSOD on Server 2012R2 during scheduled AV scan

MartinVogt

I recently installed the endpoint protection software from my UTM9 on two 2012R2 servers.

Every time i try to run a scheduled scan, the server is crashing (bsod) with no error (only kernel power error). I tried to analyze the memory dump without success... Any ideas?

Thanks

martin



This thread was automatically locked due to age.
Parents
  • 0

    Push.. I can reproduce the problem at any time on two separate servers. Does somone else has the same problem?

  • 0 in reply to MartinVogt

    Are you able to upload a couple of mini dumps (C:\windows\minidump\) to:

    http://www.osronline.com/page.cfm?name=Analyze

    Maybe Pastebin the outputs?

    Are the crashes always the same bugcheck? In someways it's better if they are.

    If not I would suggest running verifier.exe, to so so:

    Launch a command prompt as admin and run: verifier.exe

    Do the following:

    Select 2nd option - Create custom settings (for code developers)

    Select 2nd option - Select individual settings from a full list.

    Check the boxes • Special Pool • Pool Tracking • Force IRQL checking • Deadlock Detection

    Select last option - Select driver names from a list, to do so:

    Click on the Provider heading - sorts list by Provider

    Check ALL boxes where Microsoft is not the Provider

    Click on Finish

    Re-boot

    Hopefully next time it BSODs it will capture a driver if it's behaving badly which will make the dump more meaningful and more consistent.

    Beyond that you will need to provide a dump to Support as it will require the symbols.  They will probably request a full dump to be uploaded to their FTP server.

    Regards,

    Jak

Reply
  • 0 in reply to MartinVogt

    Are you able to upload a couple of mini dumps (C:\windows\minidump\) to:

    http://www.osronline.com/page.cfm?name=Analyze

    Maybe Pastebin the outputs?

    Are the crashes always the same bugcheck? In someways it's better if they are.

    If not I would suggest running verifier.exe, to so so:

    Launch a command prompt as admin and run: verifier.exe

    Do the following:

    Select 2nd option - Create custom settings (for code developers)

    Select 2nd option - Select individual settings from a full list.

    Check the boxes • Special Pool • Pool Tracking • Force IRQL checking • Deadlock Detection

    Select last option - Select driver names from a list, to do so:

    Click on the Provider heading - sorts list by Provider

    Check ALL boxes where Microsoft is not the Provider

    Click on Finish

    Re-boot

    Hopefully next time it BSODs it will capture a driver if it's behaving badly which will make the dump more meaningful and more consistent.

    Beyond that you will need to provide a dump to Support as it will require the symbols.  They will probably request a full dump to be uploaded to their FTP server.

    Regards,

    Jak

Children
  • 0 in reply to jak

    HI Jak

    Here the results...

    Instant Online Crash Analysis, brought to you by OSR Open Systems Resources, Inc.

    Show DivPrimary Analysis

    Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 8 Kernel Version 9600 MP (8 procs) Free x64
Product: Server, suite: TerminalServer DataCenter SingleUserTS
Built by: 9600.18233.amd64fre.winblue_ltsb.160210-0600
Machine Name:
Kernel base = 0xfffff802`c1203000 PsLoadedModuleList = 0xfffff802`c14d6630
Debug session time: Sun Apr 10 15:14:37.411 2016 (UTC - 4:00)
System Uptime: 0 days 0:02:01.405
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: ffffe0018f404930, The pool entry we were looking for within the page.
Arg3: ffffe0018f404bf0, The next pool entry.
Arg4: 00000000042c0010, (reserved)

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

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

OVERLAPPED_MODULE: Address regions for 'rspndr' and 'luafv.sys' overlap

BUGCHECK_STR:  0x19_20

POOL_ADDRESS: fffff802c14c4020: Unable to get special pool info
fffff802c14c4020: Unable to get special pool info
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
 ffffe0018f404930 

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME:  SavService.exe

CURRENT_IRQL:  1

IRP_ADDRESS:  ffffe001933c3be8

LAST_CONTROL_TRANSFER:  from fffff802c14a205e to fffff802c13513a0

STACK_TEXT:  
ffffd000`4df8fde8 fffff802`c14a205e : 00000000`00000019 00000000`00000020 ffffe001`8f404930 ffffe001`8f404bf0 : nt!KeBugCheckEx
ffffd000`4df8fdf0 fffff802`c12ab684 : 00000000`00000002 fffff802`c1354236 ffffe001`8ebabb10 ffffe001`0000002c : nt!ExDeferredFreePool+0x7ee
ffffd000`4df8fee0 fffff802`c12ae9b5 : ffffe001`933c3c60 ffffd000`4df90140 00000000`00000001 ffffe001`933c3ee3 : nt!IopCompleteRequest+0xc4
ffffd000`4df90040 fffff802`c1875b6f : ffffe001`933c3c60 ffffe001`933c3c01 ffff12b9`e9a95e00 00000000`00000000 : nt!IopfCompleteRequest+0x295
ffffd000`4df90180 fffff801`bb77e983 : 00000000`00000000 ffffe001`8e9d3a90 00000000`00000000 ffffe001`933c3c60 : nt!IovCompleteRequest+0x1d7
ffffd000`4df90250 fffff802`c1875911 : ffffe001`933c3c60 ffffe001`8e9d3940 00000000`00000002 ffffe001`8e304800 : spaceport!SpSpaceDeviceControl+0x193
ffffd000`4df90290 fffff801`bbef3d89 : 00000000`0004d004 ffffd000`4df903e0 00000000`00000000 ffffe001`8e304800 : nt!IovCallDriver+0x3cd
ffffd000`4df902e0 fffff801`bc07eb7d : 00000000`00000010 fffff801`bb7710f2 ffffe001`933c3c60 00000000`00010297 : CLASSPNP!ClassDeviceControl+0x1c84
ffffd000`4df90440 fffff801`bbef3e60 : ffffe001`933c3ee0 ffffe001`933c3c60 ffffe001`933c3c60 00000000`00000000 : disk!DiskDeviceControl+0x17d
ffffd000`4df904d0 fffff802`c1875911 : ffffe001`933c3c60 00000000`00000002 ffffe001`8e9d1a50 00000000`00000000 : CLASSPNP!ClassDeviceControlDispatch+0x2c
ffffd000`4df90500 fffff801`bb76c05d : ffffe001`933c3c60 ffffd000`4df905a0 ffffe001`8e9d1a50 ffffe001`8c82af40 : nt!IovCallDriver+0x3cd
ffffd000`4df90550 fffff801`bb761813 : ffffe001`933c3c00 00000000`00000000 00000000`00000000 ffffe001`933c3c60 : partmgr!PmIoctlRedirect+0x4d
ffffd000`4df905c0 fffff802`c1875911 : ffffe001`933c3c60 ffffe001`8e9d1900 00000000`00000002 00000000`00000000 : partmgr!PmFilterDeviceControl+0xd3
ffffd000`4df90610 fffff802`c15acb64 : 00000000`00000000 ffffe001`8f79b060 ffffe001`8f79b1b0 ffffe001`8d296340 : nt!IovCallDriver+0x3cd
ffffd000`4df90660 fffff802`c15ac82e : 00000000`00000000 ffffe001`8f79b060 ffffe001`933c3f28 ffffe001`933c3c60 : nt!RawReadWriteDeviceControl+0xe4
ffffd000`4df906a0 fffff802`c1875911 : ffffe001`933c3c60 ffffe001`933c3c60 00000000`00000002 00000000`00000000 : nt!RawDispatch+0xb6
ffffd000`4df90710 fffff801`bba54101 : ffffe001`8f31b060 ffffe001`8f31b060 00000000`00000002 ffffe001`8e30a150 : nt!IovCallDriver+0x3cd
ffffd000`4df90760 fffff802`c1875911 : ffffe001`933c3c60 00000000`00000002 00000000`13cbed00 fffff802`c14e9f30 : fltmgr!FltpDispatch+0xf1
ffffd000`4df907c0 fffff802`c15efc40 : 00000000`00000002 ffffd000`4df90891 ffffe001`8ebd6f20 ffffe001`8d359540 : nt!IovCallDriver+0x3cd
ffffd000`4df90810 fffff802`c16a2ab6 : ffffe001`8ebd6f20 ffffd000`4df90b80 00000000`00000250 ffffe001`8ebd6f20 : nt!IopSynchronousServiceTail+0x160
ffffd000`4df908e0 fffff802`c16702fe : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0xd86
ffffd000`4df90a20 fffff802`c135cbb3 : ffffd000`4df90b80 fffff802`c167fab3 ffffd000`00000001 00000000`13cbe558 : nt!NtDeviceIoControlFile+0x56
ffffd000`4df90a90 00000000`775d2352 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`13cbedf8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x775d2352


STACK_COMMAND:  kb

FOLLOWUP_IP: 
spaceport!SpSpaceDeviceControl+193
fffff801`bb77e983 85db            test    ebx,ebx

SYMBOL_STACK_INDEX:  5

SYMBOL_NAME:  spaceport!SpSpaceDeviceControl+193

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: spaceport

IMAGE_NAME:  spaceport.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  56a4d054

FAILURE_BUCKET_ID:  X64_0x19_20_VRF_spaceport!SpSpaceDeviceControl+193

BUCKET_ID:  X64_0x19_20_VRF_spaceport!SpSpaceDeviceControl+193

Followup: MachineOwner
---------
    This free analysis is provided by OSR Open Systems Resources, Inc.
    Want a deeper understanding of crash dump analysis? Check out our Windows Kernel Debugging and Crash Dump Analysis Seminar (opens in new tab/window)

    Show DivCrash Code Links

    Show DivLoaded Module List

    Show DivRaw Stack Contents

    Show DivDump Header Information

    Show DivStrings

  • 0 in reply to MartinVogt

    Hi There, still no ideas?

    For whatever reason this happens on the hyper-v host server 2012r2 machines only. On the Server 2012R2 VMs working fine. The BSOD ocurres always a few seconds after the scan has started.

    Thanks in advance!

    martin

Unfiltered HTML