Jump to content



Recommended Posts

  • ESET Insiders



I have a little question. Does eset v6 have problem with symlink?


We have the problem. We create network Drive, create symlink by command mklink.

After that connected to this drive via Total commander. If we try to copy files we see BSOD.


Also we create symlink to local folder - problem is not present.

If we turn off real time protection by NOD32 again see BSOD.


Thank you for help.


Edited by zloyDi
Link to comment
Share on other sites



I have the same problem after upgrading Nod32 to version 6, my network is an Ipsec network, i use spiceworks and after upgrading to version 6 of nod32 all my users see BSOD everyday.

i think it's due to Eset network filtering that scan all network traffic.

I'm trying to exclude some application that can cause nod32 to stress network traffic.


I'm accepting all sort of help on this problem if someone can give us some advices.


Thank's all for help.

Link to comment
Share on other sites

  • Administrators

Just to make sure, does BSOD occur with the latest version 6.0.316 or you have an older one installed? If possible, try to reproduce it with the latest v6 or v7 beta and let us know about your findings. An issue with symlinks pointing to a different volume was already fixed in an older build of v6.

Link to comment
Share on other sites




I have the last stable version of Nod32 Antivirus, and sometimes during the day i have all pc of my network with the last stable version of Nod32 installed who crashed.

Here is a dump analyze,



Microsoft ® Windows Debugger Version 6.2.9200.20512 AMD64
Copyright © Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\Admin\Desktop\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: srv*c:\symbols*hxxp://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.18113.amd64fre.win7sp1_gdr.130318-1533
Machine Name:
Kernel base = 0xfffff800`03a0c000 PsLoadedModuleList = 0xfffff800`03c4f670
Debug session time: Thu Sep 12 11:37:21.471 2013 (UTC + 2:00)
System Uptime: 0 days 1:55:51.008
Loading Kernel Symbols
Loading User Symbols
Loading unloaded module list
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
Use !analyze -v to get detailed debugging information.
BugCheck C2, {7, 109b, 40b0009, fffffa8015b48590}
Probably caused by : tcpip.sys ( tcpip!WfpFreeToNPagedLookAsideList+59 )
Followup: MachineOwner
3: kd> !analyze -v
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 000000000000109b, (reserved)
Arg3: 00000000040b0009, Memory contents of the pool block
Arg4: fffffa8015b48590, Address of the block of pool being deallocated
Debugging Details:
POOL_ADDRESS:  fffffa8015b48590 Nonpaged pool
BUGCHECK_STR:  0xc2_7_Icse
LAST_CONTROL_TRANSFER:  from fffff80003bb4be9 to fffff80003a81c00
fffff880`009c4958 fffff800`03bb4be9 : 00000000`000000c2 00000000`00000007 00000000`0000109b 00000000`040b0009 : nt!KeBugCheckEx
fffff880`009c4960 fffff880`01a1d969 : 00060000`0f000000 fffff800`03bb530d 00000000`00000006 ffff0000`012ac869 : nt!ExDeferredFreePool+0x1201
fffff880`009c4a10 fffff880`01bced21 : fffff880`009c4ab0 fffffa80`15b8ea50 00000000`00000001 fffffa80`15b8ea50 : tcpip!WfpFreeToNPagedLookAsideList+0x59
fffff880`009c4a40 fffff880`01aa25bb : fffffa80`15b48590 00000000`00000001 00000000`00000000 fffff880`009c4c00 : tcpip!IPSecDerefNsConnEntry+0x21
fffff880`009c4a70 fffff880`01a24f45 : 00000000`00000006 fffffa80`15b8ea50 fffffa80`12445338 fffffa80`0df14010 : tcpip! ?? ::FNODOBFM::`string'+0x199db
fffff880`009c4b30 fffff880`01a42f2e : fffffa80`1564d7a0 00000000`00000000 fffffa80`12445338 00000000`00000000 : tcpip!ProcessOutboundTransportLayerClassify+0x2d5
fffff880`009c4ce0 fffff880`01a89d44 : fffffa80`15b8ea50 fffffa80`0fff7c38 00000000`0000f758 fffff880`01a8901f : tcpip!WfpProcessOutTransportStackIndication+0x70e
fffff880`009c4ea0 fffff880`01a5d3ff : fffffa80`0fff7c38 fffffa80`0fff7cec fffff880`009c51a0 fffffa80`00000001 : tcpip!IppInspectLocalDatagramsOut+0x264
fffff880`009c4f80 fffff880`01a5fdae : 00000000`00000000 fffff880`01b03607 fffffa80`15fcf9b0 fffffa80`1564d7a0 : tcpip!IppSendDatagramsCommon+0x7ef
fffff880`009c5120 fffff880`01b32480 : fffffa80`15fcf9b0 00000000`00000004 00000000`00000004 fffffa80`15fcf9b0 : tcpip!IpNlpSendDatagrams+0x3e
fffff880`009c5160 fffff880`01abd766 : 00000000`00000000 fffff880`01a84d38 00000000`00000000 fffffa80`15fcf9b0 : tcpip!TcpTcbKeepAliveSend+0x490
fffff880`009c52d0 fffff880`01a853c6 : 00000000`00000000 00000000`00000000 00000000`00000ca8 00000000`000a9b51 : tcpip! ?? ::FNODOBFM::`string'+0x3e02d
fffff880`009c53b0 fffff800`03a8c84c : fffff880`009c54c0 00000000`0006b51d 00000000`00000000 00000000`00000001 : tcpip!TcpPeriodicTimeoutHandler+0x3f9
fffff880`009c5430 fffff800`03a8c6e6 : fffffa80`10115518 00000000`0006cc86 00000000`00000000 00000000`00000102 : nt!KiProcessTimerDpcTable+0x6c
fffff880`009c54a0 fffff800`03a8c5ce : 00000010`2f1fa9f9 fffff880`009c5b18 00000000`0006cc86 fffff880`031ef648 : nt!KiProcessExpiredTimerList+0xc6
fffff880`009c5af0 fffff800`03a8c3b7 : 00000004`19ad62c1 00000004`0006cc86 00000004`19ad62bf 00000000`00000086 : nt!KiTimerExpiration+0x1be
fffff880`009c5b90 fffff800`03a7990a : fffff880`031ec180 fffff880`031f70c0 00000000`00000002 fffff800`00000000 : nt!KiRetireDpcList+0x277
fffff880`009c5c40 00000000`00000000 : fffff880`009c6000 fffff880`009c0000 fffff880`009c5c00 00000000`00000000 : nt!KiIdleLoop+0x5a
fffff880`01a1d969 ebd8            jmp     tcpip!WfpFreeToNPagedLookAsideList+0x33 (fffff880`01a1d943)
SYMBOL_NAME:  tcpip!WfpFreeToNPagedLookAsideList+59
FOLLOWUP_NAME:  MachineOwner
IMAGE_NAME:  tcpip.sys
FAILURE_BUCKET_ID:  X64_0xc2_7_Icse_tcpip!WfpFreeToNPagedLookAsideList+59
BUCKET_ID:  X64_0xc2_7_Icse_tcpip!WfpFreeToNPagedLookAsideList+59
Followup: MachineOwner
Link to comment
Share on other sites

  • ESET Moderators



it seems that the crash was not caused by our driver "Probably caused by : tcpip.sys" and the is not any mention about ESET in the stack.

Do you have latest version of tcpip.sys installed on your system?

Link to comment
Share on other sites

the tcpip.sys version is the latest Windows version available, but i think is the tcp filter who invoke tcpip.sys that caused the BSOD.


Could you give me the list of tcp filter who invoke tcpip.sys in ESET.

Link to comment
Share on other sites

  • Administrators
Link to comment
Share on other sites

I have install the latest upgrades of windows on all my network and no new BSOD appared since the upgrade.

A couple of days more and i close the case.


Didn't find a solution, but take another way.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...