Vienna Symphonic Library Forum
Forum Statistics

184,613 users have contributed to 42,366 threads and 255,351 posts.

In the past 24 hours, we have 1 new thread(s), 7 new post(s) and 72 new user(s).

  • VEPro4(9753) and PT10 cause BSOD...

    this is the BSOD message...IoBuildPartialMdl was called with a virtual address range outside the range of the source MDL. tho i really do think this is a PT10 problem i figured i'd post here. my system is basically the same W7 Pro x64 system as it was when i built it 3 yrs ago. few if any updates as i don't need the security updates since it does not go online.

    W7 Pro x64

    002 console driver

    VEPro4 (9753)

    8gb of ram

    Q6600/P35 build (OC'd to 3.2)

    i also tried increasing the page file...hoping that would help...nada..and i also swapped out the tcpip.sys file to its' version 2...still crashed... any help from support would be GREATLY appreciated. thanks

    here is the text from one of the dumps...

    Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
    Copyright (c) Microsoft Corporation. All rights reserved.

    Loading Dump File [C:\Windows\MEMORY.DMP]
    Kernel Summary Dump File: Only kernel address space is available

    Symbol search path is: C:\Symbols\;C:\Windows\System32\
    Executable search path is:
    Windows 7 Kernel Version 7600 MP (4 procs) Free x64
    Product: WinNt, suite: TerminalServer SingleUserTS
    Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
    Machine Name:
    Kernel base = 0xfffff800`02c4e000 PsLoadedModuleList = 0xfffff800`02e8be50
    Debug session time: Sat Dec  3 18:15:10.902 2011 (GMT-8)
    System Uptime: 0 days 0:16:20.588
    Loading Kernel Symbols
    Loading User Symbols
    PEB is paged out (Peb.Ldr = 00000000`fffdf018).  Type ".hh dbgerr001" for details
    Loading unloaded module list
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *

    Use !analyze -v to get detailed debugging information.

    BugCheck 12E, {fffffa8007d1b9b8, fffffa8006e03420, fffffa8007d1ba00, 200}

    PEB is paged out (Peb.Ldr = 00000000`fffdf018).  Type ".hh dbgerr001" for details
    PEB is paged out (Peb.Ldr = 00000000`fffdf018).  Type ".hh dbgerr001" for details
    Probably caused by : tcpip.sys ( tcpip!TcpSegmentTcbSend+200 )

    Followup: MachineOwner

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

    A driver has called the IoBuildPartialMdl() function and passed it an MDL
    to map part of a source MDL, but the virtual address range specified is
    outside the range in the source MDL.  This is a driver bug.  The source
    and target MDLs, as well as the address range length to be mapped are the
    arguments to the IoBuildPartialMdl() function, i.e.;
            IN PMDL SourceMdl,
            IN OUT PMDL TargetMdl,
            IN PVOID VirtualAddress,
            IN ULONG Length
    Arg1: fffffa8007d1b9b8
    Arg2: fffffa8006e03420
    Arg3: fffffa8007d1ba00
    Arg4: 0000000000000200

    Debugging Details:

    PEB is paged out (Peb.Ldr = 00000000`fffdf018).  Type ".hh dbgerr001" for details
    PEB is paged out (Peb.Ldr = 00000000`fffdf018).  Type ".hh dbgerr001" for details


    BUGCHECK_STR:  0x12E

    PROCESS_NAME:  ProTools.exe


    LAST_CONTROL_TRANSFER:  from fffff80002d151d6 to fffff80002cbff00

    fffff880`08cc7c48 fffff800`02d151d6 : 00000000`0000012e fffffa80`07d1b9b8 fffffa80`06e03420 fffffa80`07d1ba00 : nt!KeBugCheckEx
    fffff880`08cc7c50 fffff880`01877e20 : fffffa80`061abe60 fffff880`08cc7e98 fffffa80`07cb1b20 fffff880`08cc7e98 : nt! ?? ::FNODOBFM::`string'+0x2afc
    fffff880`08cc7c90 fffff880`01876dad : 00000000`f5cc378d fffffa80`061abf20 fffffa80`07d1b9b8 fffffa80`061abfe8 : tcpip!TcpSegmentTcbSend+0x200
    fffff880`08cc7d90 fffff880`01875429 : fffffa80`07713080 00000000`00000000 00000000`00000000 00000000`00000200 : tcpip!TcpBeginTcbSend+0x4bd
    fffff880`08cc8010 fffff880`0187389a : fffff880`08cc8300 00000000`00000002 00000000`00000000 fffff880`08cc8300 : tcpip!TcpTcbSend+0x1d9
    fffff880`08cc8290 fffff880`01873688 : fffffa80`07cb1b20 fffffa80`07cb1b20 00000000`003ee7a1 00000000`00000000 : tcpip!TcpEnqueueTcbSendOlmNotifySendComplete+0x19a
    fffff880`08cc82c0 fffff880`018736db : fffff880`018787e0 fffffa80`07f1a730 fffffa80`07d35060 fffff880`016ff173 : tcpip!TcpEnqueueTcbSend+0x438
    fffff880`08cc8360 fffff800`02ccf64a : 00000000`00000001 00000000`00000001 00000000`00000000 00000000`00000000 : tcpip!TcpTlConnectionSendCalloutRoutine+0x1b
    fffff880`08cc8390 fffff880`0187960a : fffff880`018736c0 fffff880`08cc84a0 fffff880`08cc8900 fffff880`0466a6ac : nt!KeExpandKernelStackAndCalloutEx+0xda
    fffff880`08cc8470 fffff880`0468267b : fffffa80`06e6c320 fffff880`08cc8ca0 00000000`00000200 fffffa80`07d1b7b0 : tcpip!TcpTlConnectionSend+0x7a
    fffff880`08cc84e0 fffff880`04669423 : 00000000`00000000 fffffa80`07a0bfb8 fffffa80`06e6c320 fffffa80`07a0be10 : afd!AfdFastConnectionSend+0x38b
    fffff880`08cc86a0 fffff800`02fd8113 : 00000000`00000200 fffffa80`06d16750 00000000`19b0f948 fffffa80`00000001 : afd!AfdFastIoDeviceControl+0x413
    fffff880`08cc8a10 fffff800`02fd8c06 : 00000000`00000000 00000000`00001014 00000000`00000001 00000000`00000000 : nt!IopXxxControlFile+0x373
    fffff880`08cc8b40 fffff800`02cbf153 : fffff880`08cc8ca0 fffffa80`06bfd330 00000000`00000000 fffff880`08cc8c00 : nt!NtDeviceIoControlFile+0x56
    fffff880`08cc8bb0 00000000`749f2dd9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
    00000000`1949f0f8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x749f2dd9


    fffff880`01877e20 4c8b4b18        mov     r9,qword ptr [rbx+18h]


    SYMBOL_NAME:  tcpip!TcpSegmentTcbSend+200

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: tcpip

    IMAGE_NAME:  tcpip.sys


    FAILURE_BUCKET_ID:  X64_0x12E_tcpip!TcpSegmentTcbSend+200

    BUCKET_ID:  X64_0x12E_tcpip!TcpSegmentTcbSend+200

    Followup: MachineOwner

  • Karel?? could you chime in on this please?

  • That is not a VEPro issue, it looks like an ethernet driver issue. Make sure you are running the latest updates of everything, all Windows patches and check for the latest drivers of your ethernet chip.

  • thanks for your reply Martin. i'm confused with the answer tho. i'm not using the ethernet connection...everything is running on 1 rig...???

  • Certain communication on the computer will happen using the tcp stack, regardless if you are using it in a network or not. This driver is malfunctioning. I would suspect a messed up Windows installation (most likely) or faulty system components, perhaps bad RAM.

  • thanks again Martin for the explanation. this just started happening in PT10 and my W7 installation has been solid for 3 years now. so i will check Services to make sure nothing is turned off there and i will test and re-seat my ram. thanks again!!! i will post back with my findings.

  • well all seems well[Y] reseating the ram appears to have done the trick. thanks again Martin!!!

  • well...might've spoken too soon...had 1 more BSOD yesterday in 10hrs...which is a HUGE improvement tho.  i'm feeling more confident that it really was/is a physical component thing as opposed software. i'll post back as i continue trouble-shooting. and i ran W7 memory tester which uncovered to physical errors with the ram itself...

  • Is it the same driver that BSOD's?