Bug 590603 - Ethernet-NDIS Test 6.5 caused BSOD in WHQL network testing for Windows2008 R2
Ethernet-NDIS Test 6.5 caused BSOD in WHQL network testing for Windows2008 R2
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virtio-win (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Yan Vugenfirer
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-10 06:03 EDT by Xiaoli Tian
Modified: 2010-05-18 23:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-18 23:38:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot of BSOD (144.82 KB, image/png)
2010-05-10 06:03 EDT, Xiaoli Tian
no flags Details
Minidunp file of BSOD (262.53 KB, application/octet-stream)
2010-05-10 06:06 EDT, Xiaoli Tian
no flags Details
Debug analysis of kernel memory dump file (24.56 KB, text/plain)
2010-05-10 22:28 EDT, Xiaoli Tian
no flags Details

  None (edit)
Description Xiaoli Tian 2010-05-10 06:03:57 EDT
Created attachment 412781 [details]
screenshot of BSOD

Description of problem:
BSOD when running test case :start ndis test client

Version-Release number of selected component (if applicable):
virtio-win driver version:05/03/2010,6.0.209.605
kernel:2.6.32-19.el6,x86_64


How reproducible:
always

Steps to Reproduce:
1.prepare to test WHQL network 
2.start to run NDIS Test 6.5


  
Actual results:
BSOD

Expected results:
Pass

Additional info:
Screen shot of BSOD and Minidump files will be attached.
Comment 1 Xiaoli Tian 2010-05-10 06:06:03 EDT
Created attachment 412782 [details]
Minidunp file of BSOD
Comment 3 RHEL Product and Program Management 2010-05-10 08:10:12 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 4 Xiaoli Tian 2010-05-10 22:28:10 EDT
Created attachment 413023 [details]
Debug analysis of kernel memory dump file
Comment 5 Yaniv Kaul 2010-05-11 02:27:58 EDT
1. Why not supply the analysis with correct symbols?
2. Post the stack here, so it could be searched via bugzilla in the future.
Comment 6 Xiaoli Tian 2010-05-13 03:34:30 EDT
the symbol file path is set
as:SRV:*c:\symbols*\http://msdl.microsoft.com/download/symbols 
however it always said it couldn't find the correct symbols.

the analysis stack is:

oading Dump File [C:\Users\DTMLLUAdminUser\Desktop\MEMORY.DMP]

Kernel Summary Dump File: Only kernel address space is available

Symbol search path is:
SRV*C:\symbols\*http://msdl.mcirosoft.com/download/symbols
******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************



Use !analyze -v to get detailed debugging information.



BugCheck 7E, {ffffffff80000003, fffff800014cf6a8, fffff88004806978,
fffff880048061e0}



*** ERROR: Module load completed but symbols could not be loaded for
ndprot62.sys


0: kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************



SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)

This is a very common bugcheck.  Usually the exception address pinpoints

the driver/function that caused the problem.  Always note this address

as well as the link date of the driver/image that contains this address.

Arguments:

Arg1: ffffffff80000003, The exception code that was not handled

Arg2: fffff800014cf6a8, The address that the exception occurred at

Arg3: fffff88004806978, Exception Record Address

Arg4: fffff880048061e0, Context Record Address



Debugging Details:
ADDITIONAL_DEBUG_TEXT:  

Use '!findthebuild' command to search for the target build information.

If the build information is available, run '!findthebuild -s ; .reload' to set
symbol path and load symbols.

FAULTING_MODULE: fffff80001467000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4b082704

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are
invalid
FAULTING_IP: 

nt!DbgBreakPointWithStatus+48

fffff800`014cf6a8 c3              ret

EXCEPTION_RECORD:  fffff88004806978 -- (.exr 0xfffff88004806978)

ExceptionAddress: fffff800014cf6a8
(nt!DbgBreakPointWithStatus+0x0000000000000048)

   ExceptionCode: 80000003 (Break instruction exception)

  ExceptionFlags: 00000000

NumberParameters: 1

   Parameter[0]: 0000000000000002

CONTEXT:  fffff880048061e0 -- (.cxr 0xfffff880048061e0)

rax=0000000000000002 rbx=fffffa8006426370 rcx=fffff880057867a0

rdx=fffff88004800044 rsi=fffffa8004ee0890 rdi=fffff880057867e5

rip=fffff800014cf6a7 rsp=fffff88004806bb8 rbp=0000000000000080

 r8=fffff88004806c48  r9=fffff88005780002 r10=0000000000000000

r11=fffff88004806c08 r12=fffffa8006a05098 r13=fffff88005758140

r14=0000000000000000 r15=fffff80001314080

iopl=0         nv up ei pl nz na po nc

cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206

nt!DbgBreakPointWithStatus+0x47:

fffff800`014cf6a7 cc              int     3

Resetting default scope

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x7E

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff800015662ab to fffff800014cf6a7

STACK_TEXT:  

fffff880`04806bb8 fffff800`015662ab : fffffa80`06426370 fffff800`01515b14
fffffa80`06426370 fffff880`05680edd : nt!DbgBreakPointWithStatus+0x47

fffff880`04806bc0 fffff880`056ed601 : fffffa80`069ce100 fffffa80`06426370
fffff880`057867f0 00000000`00000000 : nt!DbgPrompt+0x3b

fffff880`04806c10 fffff880`0571123a : fffff880`00000001 fffff880`05791ef0
00000000`00000691 00000000`00000000 : ndprot62+0x7d601

fffff880`04806c70 fffff880`05711005 : fffffa80`06a05040 00000000`00000001
fffffa80`0684af40 fffff800`0197dc3c : ndprot62+0xa123a

fffff880`04806cb0 fffff880`057581db : fffffa80`06a05040 00000000`00000000
fffff800`01467000 00000000`00000000 : ndprot62+0xa1005

fffff880`04806cf0 fffff800`0177ca86 : fffffa80`06a05098 fffffa80`00000000
00000000`00000000 fffff800`014cf487 : ndprot62+0xe81db

fffff880`04806d40 fffff800`014b5b06 : fffff800`01651e80 fffffa80`06426370
fffffa80`04f62b60 fffff880`01422a90 : nt!PsCreateSystemThread+0x6f2

fffff880`04806d80 00000000`00000000 : fffff880`04807000 fffff880`04801000
fffff880`04806900 00000000`00000000 : nt!KeTestAlertThread+0x93a

FOLLOWUP_IP: 

ndprot62+7d601

fffff880`056ed601 8b442440        mov     eax,dword ptr [rsp+40h]

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  ndprot62+7d601

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: ndprot62

IMAGE_NAME:  ndprot62.sys

STACK_COMMAND:  .cxr 0xfffff880048061e0 ; kb

BUCKET_ID:  WRONG_SYMBOLS
Comment 7 Yaniv Kaul 2010-05-13 03:42:08 EDT
I would not find the symbols for ndprot62.sys - as this is part of WHQL, and MS has not released symbols for it. It should have found symbols for the rest of the OS files (and for our drivers, if you've placed them correctly in c:\symbols - have you?). Lastly, when you change the symbols path, don't forget to reload (.reload command).
Also, please make sure you are using the symbols path correctly:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
(not SRV: ...)
Comment 8 Xiaoli Tian 2010-05-13 04:40:54 EDT
(In reply to comment #7)
> I would not find the symbols for ndprot62.sys - as this is part of WHQL, and MS
> has not released symbols for it. It should have found symbols for the rest of
> the OS files (and for our drivers, if you've placed them correctly in
> c:\symbols - have you?). Lastly, when you change the symbols path, don't forget
> to reload (.reload command).
> Also, please make sure you are using the symbols path correctly:
> SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
> (not SRV: ...)   
 
Yeah,I downloaded symbols of our driver from this link:
"http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.2-0/virtio-win-1.1.2-0-pdbs.zip" and placed netkvm.pdb in the path "c:\symbols\"

The symbol file path is  SRV*c:\symbols*http://msdl.microsoft.com/download/symbols definitely
Comment 9 Xiaoli Tian 2010-05-18 23:38:36 EDT
I have tested this job on the latest RHEL6.0 ,It passes with Errata 1783
I'll close it as not a bug

Note You need to log in before you can comment on or make changes to this bug.