none
(SMB) Sessions werden nicht getrennt RRS feed

  • Frage

  • Hallo zusammen,

    die Geschichte kurz zusammen gefasst ;P

    - Zielsystem Windows Server 2008 R2 in unserer DMZ

    - Kollege greift mit einem Java Script per SMB auf eine Freigabe zu und kopiert/verschiebt/erstellt/löscht Dateien (die Scripte laufen auf anderen 2003er/2008er R2 Servern ohne Probleme)

    - unregelmäßig beenden sich die Scripte mit einem Timeout. Daraufhin angefangen nach der Ursache zu suchen.

    - auf dem Server ein "net session" ausgeführt, gibt Sessions aus mit wunderlichem Inhalt: z.B. Quellsystem mit Benutzer hat noch 4583478 Dateien geöffnet mit einer Ruhezeit von 11056 Tagen... Die Session wurde aber erst vor wenigen Minuten oder Stunden geöffnet, die Ausgabe von "net session" ist also scheinbar Nonsense.

    - Diese halboffenen Sessions "vermehreren" sich dann mit der Zeit, weil immer mal wieder eine Session nicht richtig geschloßen wird und die Scripte regelmäßig ausgeführt werden

    - Diese Sessions bekommt man auch nicht geschloßen. Auf dem Quellsystem sind diese natürlich nicht mehr vorhanden.

    - Ab und an, wenn ich ein "net session" ausführe, stürzt sogar der komplette Server ab.

    - Im erstellten memory.dmp sieht es für mich noch einem Buffer-Overflow aus. Weiter unten habe ich das Ganze mal angefügt.

    - Das Problem mit dem Timeout der Scripte scheint für mich also in Verbindung zu stehen mit den offenen Sessions, da der Server in diese Richtung auch sehr langsam reagiert wenn ich mir die offnen Sitzungen über die Computerverwaltung anschaue und es dann ja sogar bis zu einem Absturz führen kann.

    Hat jemand überhaupt noch eine Idee oder einen Ansatz für mich wie ich an das Problem noch heran gehen könnte? Bin etwas Ratlos...

    :)

     

     

    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    PAGE_FAULT_IN_NONPAGED_AREA (50)
    Invalid system memory was referenced.  This cannot be protected by try-except,
    it must be protected by a Probe.  Typically the address is just plain bad or it
    is pointing at freed memory.
    Arguments:
    Arg1: fffff8a008b7f880, memory referenced.
    Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
    Arg3: fffff80001526986, If non-zero, the instruction address which referenced the bad memory
     address.
    Arg4: 0000000000000000, (reserved)

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


    READ_ADDRESS:  fffff8a008b7f880

    FAULTING_IP:
    nt!RtlTimeToSecondsSince1980+6
    fffff800`01526986 488b09          mov     rcx,qword ptr [rcx]

    MM_INTERNAL_CODE:  0

    DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

    BUGCHECK_STR:  0x50

    PROCESS_NAME:  svchost.exe

    CURRENT_IRQL:  0

    TRAP_FRAME:  fffff88004179530 -- (.trap 0xfffff88004179530)
    NOTE: The trap frame does not contain all registers.
    Some register values may be zeroed or incorrect.
    rax=000000003b1f3401 rbx=0000000000000000 rcx=fffff8a008b7f880
    rdx=fffff88004179778 rsi=0000000000000000 rdi=0000000000000000
    rip=fffff80001526986 rsp=fffff880041796c0 rbp=fffff88004179810
     r8=fffff88004179717  r9=01cc24e89aa503a0 r10=fffff8a007334020
    r11=fffff88004179710 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0         nv up ei ng nz na po nc
    nt!RtlTimeToSecondsSince1980+0x6:
    fffff800`01526986 488b09          mov     rcx,qword ptr [rcx] ds:fffff8a0`08b7f880=????????????????
    Resetting default scope

    LAST_CONTROL_TRANSFER:  from fffff8000150bf14 to fffff8000148b740

    STACK_TEXT: 
    fffff880`041793c8 fffff800`0150bf14 : 00000000`00000050 fffff8a0`08b7f880 00000000`00000000 fffff880`04179530 : nt!KeBugCheckEx
    fffff880`041793d0 fffff800`0148982e : 00000000`00000000 00000000`18fc6e80 fffff8a0`00adaf00 fffff8a0`009ee060 : nt! ?? ::FNODOBFM::`string'+0x42837
    fffff880`04179530 fffff800`01526986 : 00000000`00000000 fffff880`0243a890 fffff8a0`00d9b010 fffff8a0`00d9b010 : nt!KiPageFault+0x16e
    fffff880`041796c0 fffff880`0243ced2 : fffff8a0`00d9b0c8 00000000`00000000 00000000`00000000 00000000`00000001 : nt!RtlTimeToSecondsSince1980+0x6
    fffff880`041796f0 fffff880`024402dc : fffff8a0`3b1f3401 00000000`00000000 fffffa80`3b21c143 01cc266d`fa20b01e : srvnet!FillSessionInfoBuffer+0xa2
    fffff880`04179770 fffff880`02441914 : 00000000`0000008d 00000000`00000000 00000980`00002000 fffff8a0`00d9b010 : srvnet!SvcEnumApiHandler64+0xcc
    fffff880`04179800 fffff880`0243ff23 : fffffa80`0363a690 fffff8a0`053d3401 fffff880`00000001 00000000`00000002 : srvnet!SvcSessionEnum+0x44
    fffff880`04179860 fffff880`0244e570 : fffffa80`039c8ab0 00000000`00146027 fffffa80`039c89e0 fffff800`0177a27a : srvnet!SrvAdminProcessFsctl+0x403
    fffff880`041798e0 fffff880`024307fe : fffffa80`039c8ab0 00000000`00146027 fffffa80`039c89e0 fffff800`015bf4d3 : srvnet! ?? ::NNGAKEGL::`string'+0x707
    fffff880`04179960 fffff880`0244d834 : fffffa80`039c89e0 00000000`00000000 fffff880`04179ca0 fffffa80`02de2070 : srvnet!SrvNetDeviceControl+0x9e
    fffff880`041799e0 fffff800`017a4547 : fffffa80`02de2070 fffff880`04179ca0 fffffa80`039c8af8 fffffa80`039c89e0 : srvnet!SrvNetDefaultDispatch+0x24
    fffff880`04179a10 fffff800`0176d80a : 00000000`0160ea60 00000000`00001150 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x607
    fffff880`04179b40 fffff800`0148a993 : fffffa80`02a756e0 00000000`0160e9d8 fffff880`04179bc8 00000000`00000000 : nt!NtFsControlFile+0x56
    fffff880`04179bb0 00000000`76e9fa4a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
    00000000`0160e9b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76e9fa4a


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    srvnet!FillSessionInfoBuffer+a2
    fffff880`0243ced2 448b9c2480000000 mov     r11d,dword ptr [rsp+80h]

    SYMBOL_STACK_INDEX:  4

    SYMBOL_NAME:  srvnet!FillSessionInfoBuffer+a2

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: srvnet

    IMAGE_NAME:  srvnet.sys

    DEBUG_FLR_IMAGE_TIMESTAMP:  4c7732f4

    FAILURE_BUCKET_ID:  X64_0x50_srvnet!FillSessionInfoBuffer+a2

    BUCKET_ID:  X64_0x50_srvnet!FillSessionInfoBuffer+a2

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

    Donnerstag, 9. Juni 2011 07:18

Alle Antworten