Rufus doesn't work while using Bitdefender Internet Security 2015

[Opptur]

Hello! As the title says, Rufus cannot write the boot record while using Bitdefender Internet Security 2014/2015 (both versions). After I uninstalled it and rebooted my computer, everything worked just fine. Even after I disabled every option of that software, the problem didn't go away. I even added Rufus to every exception list, but that had no effect.

I have seen another couple of problems that Rufus had with other antivirus software (ESET NOD32). Can you please look into it? I have opened a support ticket on Bitdefender site as well.

Rufus version: 1.4.9.506
Syslinux versions: 4.07, 5.10
Windows version: Windows XP SP3 32 bit
Locale ID: 0x0409
Found USB 1.0 device 'ADATA ADATA UFD USB Device' (125F:312B)
Using autorun.inf label for drive G: 'Install Ubuntu'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1920, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x000A5553
Drive has a Syslinux Master Boot Record
Partition 1:
  Type: FAT32 LBA (0x0c)
  Size: 14.7 GB (15794700288 bytes)
  Start Sector: 2048, Boot: Yes, Recognized: Yes
Scanning image...
Disc image is an ISO9660 image
Will use /isolinux/isolinux.cfg for Syslinux
Detected Isolinux version: 4.05 (from '/isolinux/isolinux.bin')
ISO label: 'Ubuntu 14.04.1 LTS i386'
  Size: 1033046016 bytes
  Has a >64 chars filename: No
  Has Symlinks: Yes
  Has a >4GB file: No
  Uses ReactOS: No
  Uses KolibriOS: No
  Uses EFI: No
  Uses Bootmgr: No
  Uses WinPE: No
  Uses isolinux: Yes (4.05)
    With an old menu.c32: No
    With an old vesamenu.c32: No
Using ISO: ubuntu-14.04.1-desktop-i386.iso

Format operation started
Requesting disk access...
Caution: Opened drive \\.\PHYSICALDRIVE1 for write access
Will use 'G:' as volume mountpoint
I/O boundary checks disabled
Analyzing existing boot records...
Drive has a Syslinux Master Boot Record
Volume has an unknown Partition Boot Record
Deleting partitions...
Closing existing volume...
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Partitioning (MBR)...
Waiting for logical drive to reappear...
Formatting (FAT32)...
Using cluster size: 8192 bytes
Quick format was selected
Creating file system: Task 1/5 completed
Creating file system: Task 2/5 completed
Creating file system: Task 3/5 completed
Creating file system: Task 4/5 completed
Creating file system: Task 5/5 completed
Format completed.
Writing master boot record...
Drive has a Zeroed Master Boot Record
Partition is already FAT32 LBA...
Set bootable USB partition as 0x80
Using Syslinux MBR
Found volume GUID \\?\Volume{fefc2cd5-1710-11e4-ba9c-0015f2351b5d}\
Installing Syslinux 4.05...
Successfully wrote 'ldlinux.sys'
Caution: Opened drive \\?\Volume{fefc2cd5-1710-11e4-ba9c-0015f2351b5d} for write access
Could not write Syslinux boot record: [0x00000005] Access is denied.
\\?\Volume{fefc2cd5-1710-11e4-ba9c-0015f2351b5d}\ was already mounted as G:\
Re-mounted volume as 'G:' after error

Found USB 1.0 device 'ADATA ADATA UFD USB Device' (125F:312B)
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 1920, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x00085433
Drive has a Syslinux Master Boot Record
Partition 1:
  Type: FAT32 LBA (0x0c)
  Size: 14,7 GB (15794700288 bytes)
  Start Sector: 2048, Boot: Yes, Recognized: Yes

[pbatard]

The problem, really, is that some security solutions seem to want to keep a lock on some USB files or devices, which they shouldn't do.

As opposed to other USB formatting solutions, Rufus always attempts to request exclusive access to the USB when it's doing an operation that can potentially change it's configuration, to ensure that other software that may be accessing the USB doesn't run into an issue. This can pretty much be equated to Rufus saying: "Hey, I see that you are sitting on the branch that I am about to saw. I guess this leaves me no choice but stop what I was planning to do, to prevent you from falling...".

In this case, Rufus was about to rewriting a boot record, but detected that other software was accessing files on the USB (with a lock on them). Since modifying a boot record while files are being accessed has the potential to produce unexpected results, the safe course of action is to halt the operation.

Now, I do have plans to look into reporting which application is preventing access to the drive (#312), but it will probably be a while before I do that. I was also very recently in touch with the ESET people, who had a similar issue in their security software but fixed it in the latest version (which is why ESET was recently removed from this list), so I would tend to believe that this issue should be addressed by the Bitdefender people.

[Opptur]

Got it. As I said, I have opened a support ticket on Bitdefender website, and I am waiting for a response from them. I'll post here as soon as I manage to do something.

[pbatard]

I'm going to close this issue now. Will reopen if there's an update from the Bitdefender devs.

[Opptur]

They are currently investigating. They managed to reproduce the issue. It seems it is a WinXP only problem. I'll keep you updated.

[Opptur]

The incompatibility has been solved by Bitdefender in their latest engine version.

[pbatard]

Thanks for the follow up. I have now taken BitDefender off the list of software that is incompatible with Rufus.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.