NOD32 crashes my servers!

Discussion in 'NOD32 version 1 Forum' started by slider, Dec 30, 2002.

Thread Status:
Not open for further replies.
  1. slider

    slider Registered Member

    Joined:
    Dec 30, 2002
    Posts:
    11
    Location:
    Utah (USA)
    I'm using NOD32 on my two Windows 2000 Servers, and amon.sys is causing a BSOD crash when my backups are run. We've figured out the problem and have instituted workarounds, but wanted to make sure Eset knows about the problem.

    The problem is this: using Windows Backup utility amon.sys will crash the system as soon as the backup file gets to 4GB in size. If we divide the backup schedule to make finished backup files less than 4GB in size then the crash doesn't occur. Instead of two or three nicely organized backup jobs, we have to have 15 or so to make sure the backup files don't approach 4GB. These are automated backups set to run each night, so there is no way we can disable the scanner before running the backups, unless there's an automated way of doing that I'm not aware of. I also haven't looked at the possibility of excluding an entire directory (our backup folder).

    Anyone know if this is a known issue? Am I doing something wrong to cause this? Are there better workarounds than simply creating a myriad of backup jobs to keep the final backups under 4GB?

    TIA.
     
  2. Phil

    Phil Registered Member

    Joined:
    Oct 24, 2002
    Posts:
    248
    As a work-around, see which file AMON is scanning and exclude it from scanning. I haven't checked it myself but it must be either ntbackup or the bkf file itself. You could run a quick test by picking a directory or two and back them up while watching AMON to see what it is counting/scanning.

    HTH
    Phil
     
  3. slider

    slider Registered Member

    Joined:
    Dec 30, 2002
    Posts:
    11
    Location:
    Utah (USA)
    It's most definitely the scanning of the bkf files that's causing the crash. We tweaked the backups to get the finished backup below the 4GB limit to prevent the crash.

    I could have sworn both of my servers were having this problem, but I saw my one server had made a backup that was 4.5GB in final size. That made me think about it and I don't think this other server was getting the blue screens. I must have dreamt it or something.

    So to give some more details:

    The server that's crashing is a dual CPU machine, backing up using NTBackup across the network to a shared hard drive on the above mentioned server that isn't having the problem. amon.sys will BSOD the dual CPU server if the backup passes 4GB in size. Our lead developer told me it may be that NOD32 has a problem with memory addressing in the dual CPU environment trying to deal with files of that size. If we keep the backups less than 4GB in final size the server does not crash from the backup job.

    Should I take this directly to Eset or do they frequent these forums?
     
  4. Paul Wilders

    Paul Wilders Administrator

    Joined:
    Jul 1, 2001
    Posts:
    12,472
    Location:
    The Netherlands
    slider,

    Eset staff members do frequent this dedicated Eset Forum. I'll make sure this issue/thread will be attended to.

    regards.

    paul
     
  5. slider

    slider Registered Member

    Joined:
    Dec 30, 2002
    Posts:
    11
    Location:
    Utah (USA)
    Thanks Paul. We're expanding our server lineup, and this issue definitely has bearing on what we'll buy to put on our new boxes.
     
  6. jan

    jan Former Eset Moderator

    Joined:
    Oct 25, 2002
    Posts:
    804
    Hi slider,


    OK, we are checking the problem and you will hear from us soon.

    rgds, :)

    jan
     
  7. slider

    slider Registered Member

    Joined:
    Dec 30, 2002
    Posts:
    11
    Location:
    Utah (USA)
    Thanks Jan.
     
  8. rodzilla

    rodzilla Registered Member

    Joined:
    Jun 15, 2002
    Posts:
    653
    Location:
    australia
    > The server that's crashing is a dual CPU machine, backing up using NTBackup across the network to a shared hard drive on the above mentioned server that isn't having the problem. amon.sys will BSOD the dual CPU server if the backup passes 4GB in size. Our lead developer told me it may be that NOD32 has a problem with memory addressing in the dual CPU environment trying to deal with files of that size. If we keep the backups less than 4GB in final size the server does not crash from the backup job.

    If the shared hard drive is FAT32 it may have generic problems with files larger than 4GB ... and converting it to NTFS might solve your problem. (Just a passing thought.) :)
     
  9. rodzilla

    rodzilla Registered Member

    Joined:
    Jun 15, 2002
    Posts:
    653
    Location:
    australia
    Another passing thought ........

    Try unchecking "Create" in the AMON "Targets".
     
  10. jan

    jan Former Eset Moderator

    Joined:
    Oct 25, 2002
    Posts:
    804
    Hi slider,
    We have tried it on our W2K Servers with 9GB backup without any problems.

    Please try to describe the situation closer:

    - what file system/s is/are are on the related disks?

    - what is written on the blue screen when it appears?

    - send me the Minidump of the problem disks - I'll send you a private message

    rgds, :)


    jan
     
  11. slider

    slider Registered Member

    Joined:
    Dec 30, 2002
    Posts:
    11
    Location:
    Utah (USA)
    Blue screen:

    *** STOP: XXXXXXXX (XxXXXXXXX, XxXXXXXXX, XxXXXXXXX, XxXXXXXXX)
    KMODE_EXCEPTION_NOT_HANDLED
    *** Address: XXXXXXXX, Base at XXXXXXXX, DateStamp XXXXXXXX - amon.sys
    Beginning dump of physical memory...


    Problem server:
    • Dual Athlon XP 1600+
    • Asus A7M-266D
    • 1GB PC2100 Crucial DDR RAM
    • Windows 2000 Server SP2
    • Full NTFS single primary partition per disk on all server volumes
    Backup server:
    • Windows 2000 Server SP3
    • 120GB IBM hard drive formatted NTFS with a single primary partition (upgraded to dymanic) shared on the network
    Minidump sent by email.
     
Thread Status:
Not open for further replies.