BSOD when using CB (2.2.127000.12) in synchronization mode with external HDD?

Hi,
I am using the free version of Comodo Backup (latest version 2.2.127000.12) backing certain directories up to an external Seagate (Free Agent) Drive which is connected to my ABIT Mobo via e-SATA.
OS: Windows 7 Professional (64-bit). Latest drivers for all peripherals are installed (at least to my knowledge).

For the last few months I periodically have been getting BSOD’s with the BAD_POOL_HEADER message. I suspected that the synchronization backup was causing intermittent system hangs (for a few seconds usually), but BSOD’s happened as well.

On my most recent crash I used WinDbg and it identified the CBUF.sys file as the culprit (whether that’s true or not, I don’t know). Below find an excerpt of the analysis. I am also attaching the minidump file, but I also have the memory.dmp file (but that’s rather large).

Any advice/hints would be appreciated. I really like the synchronization feature as it is more immediate than the periodic backup.


  •                                                                         *
    
  •                    Bugcheck Analysis                                    *
    
  •                                                                         *
    

Use !analyze -v to get detailed debugging information.

BugCheck 19, {20, fffffa8006a9f0a0, fffffa8006a9f0f0, 405000a}

*** ERROR: Module load completed but symbols could not be loaded for CBUFS.sys
*** ERROR: Module load completed but symbols could not be loaded for SiWinAcc.sys
Probably caused by : CBUFS.sys ( CBUFS+dd67 )

Followup: MachineOwner

0: kd> !analyze -v


  •                                                                         *
    
  •                    Bugcheck Analysis                                    *
    
  •                                                                         *
    

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffffa8006a9f0a0, The pool entry we were looking for within the page.
Arg3: fffffa8006a9f0f0, The next pool entry.
Arg4: 000000000405000a, (reserved)

Debugging Details:

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: fffffa8006a9f0a0 Nonpaged pool

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: SearchIndexer.

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002dab6d3 to fffff80002c78740

STACK_TEXT:
fffff88007e8e8e8 fffff80002dab6d3 : 0000000000000019 0000000000000020 fffffa8006a9f0a0 fffffa8006a9f0f0 : nt!KeBugCheckEx
fffff88007e8e8f0 fffff88001042d67 : fffff88007e8ea68 fffffa8006a9f0b0 fffffa8000676e65 fffffa8003d2f474 : nt!ExDeferredFreePool+0x12c4
fffff88007e8e9a0 fffff88001042fc2 : fffffa8003dae010 0000000000000000 fffffa8003fe67b0 0000000000000092 : CBUFS+0xdd67
fffff88007e8e9f0 fffff8800105b02e : 0000000006a8e600 0000000000000000 00000000000000a8 fffffa8003dae010 : CBUFS+0xdfc2
fffff88007e8ea60 fffff80002f5b62d : 00000000000000a8 fffff88007e8eca0 0000000000000000 fffffa8003f8df20 : SiWinAcc+0x102e
fffff88007e8ea90 fffff80002c77993 : 000000000000068c fffffa80065fe060 0000000006a8e668 fffff880000000a8 : nt!NtSetInformationFile+0x909
fffff88007e8ebb0 000000007756ffca : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
0000000006a8e648 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x7756ffca

STACK_COMMAND: kb

FOLLOWUP_IP:
CBUFS+dd67
fffff880`01042d67 49892c24 mov qword ptr [r12],rbp

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: CBUFS+dd67

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: CBUFS

IMAGE_NAME: CBUFS.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4b461afd

FAILURE_BUCKET_ID: X64_0x19_20_CBUFS+dd67

BUCKET_ID: X64_0x19_20_CBUFS+dd67

Followup: MachineOwner

[attachment deleted by admin]

Hi

2.2 version has some known issues related to synchronization.
A new version that is not in BETA stage will be released soon.
The 3.0 version contains smart synchronization (block level synchronization).
If a single byte changes in a large file, it will not process the entire file again, just a single block (512 bytes), this helps saving bandwidth.

Thanks