I have a weird problem with UBCD for some days now on one of my machines. It used to work. Now it doesn't. The problem is that whatever I choose from the menu the launch of the program will eventually fail. Once I hit enter all the commands that seem to be in _MODBOOT.BAT are echoed to the screen and run thru very quickly (which was not the case before, this is usually hidden). First on A:, then on Q: (ramdisk). Finally, that comes to an end asking (this is not literal) "pause MODBOOT: CTRL-C to abort, any key to skip/run 2peruse.bat". If I hit a key it runs thru more lines and then asks another question of this kind. And that goes on and on and on, until it finally says something about "skipping unpacking autorun3.cab" and throws me to the DOS prompt. This happens with every program and with every program startup option I try.
What's going on here?
I think it used to run a few weeks ago on that machine, but I'm not 100% positive. It runs fine on another machine were I tested the CD.
The only change to the hardware in the meantime was a BIOS update because the AMD virtualization support wasn't correctly working (the update fixed that). I disabled VT in the BIOS, but this didn't change the problem with UBCD.
The reason why I want to run UBCD is that I want to run Samsung ES-Tools from it to check a certain harddisk. SE-Tool *sure* used to work on that machine, but suddenly fails. It is stuck on the "Autodetection" line and I can't move the cursor to select a disk for diagnostics. So, the only thing it does when I hit the cursor key or enter is another quick autodetection. That's why I wanted to check if the ES-Tools on UBCD has the same problem.

May I suggest breaking the problem in several parts?

Could you put the HDD you want to test in another computer and check if those CD's are running successfully?

Which version of UBCD are you using?

Have you tried with the latest Es-tools (recently updated)?

Is it possible that the BIOS update changed also some settings in the BIOS that prevents running those boot cd's correctly? Have you tried setting the "basic" settings (or the "optimal" settings) in the BIOS, then rebooting into the BIOS and setting the desired settings again?

Since the CD's are running correctly in other computers, is it possible that the problem is in the specific optical drive or the connection, instead of being in the optical media?

Have you checked the optical media against the iso? (There are several tools to do that.)

All these paragraphs can "break" the problem in several parts, and may help you resolve the problem.

It is not a problem with the CD or drive. The UBCD program launch doesn't work on this specific machine and, coincidently, ES-Tools also has a problem on this machine. It is all fine if I boot any of the two CDs on another machine. I haven't checked all machines, so I can't say if there is any second machine displaying the same problem.
I'm not 100% sure, but convinced to a certain extent that the BIOS update must have made the difference. The main difference between the firmware versions is that a certain part of the AMD virtualization support did not work with firmware version F13, e.g. Hyper-V would not start and show these errors althout Virtualization was enabled in BIOS:

After the upgrade to F16b Hyper-V works just fine. (SVM = secure virtual machine extensions or so.) I assume that a "CPU ID" update did this, although this was for other (newer) processors.
It is a Gigabyte board GA-M51GM-S2G with an Athlon 64 4200+ and the changelog lists the folowing changes from 13 to 16b:

AFAICS, none of the BIOS settings were changed by the upgrade and the OS (2008 R2 x86-64) is working just fine.
I find it weird that only the program launch with modboot.bat doesn't work. Until I get to the menu everything appears to be just fine. I had hoped that someone would know this symptom that the script code suddenly "runs thru" on the screen instead of being carried out (at least it looks like that).
I went to another PC for the harddisk check, but I would have preferred to get it on this one running as this is the one I used to use for this kind of task because it is best suited for adding more disks and I can reach it best, the other ones are a bit less comfortable to handle. And, of course, it appears that I will never be able to use UBCD on it in case I *need* it

In theory, according to the info you provided, you can't be 100% sure the CD drive isn't the problem. You may try verifying the CD media against the downloaded/customized iso image, using the same computer. Several (not all) burning tools have the "verify" function. I am not talking about the setting to "verify" right after the CD was burned, but a separate "verify" function. There are also specific freeware tools that doesn't burn a CD, but only check / compare the burned CD against an iso image.



Note: I apologize in advance if you already know the next info, but some other (newbie) user might want to know what to do.

Usually, current OS's adapt to the new BIOS. But DOS is not such an OS (meaning, something like "PlugAndPlay").

In any case, it is recommended to "clean" the BIOS data after a BIOS update, and then set it again to what it is suppose to be.

I have experience with Gigabyte mobos + AwardBIOS. I have seen situations where it "seems" that everything is fine after a BIOS update, but after a while I find that "something is not exactly working as it should". Clearing the BIOS data solved the problem.

There are command line parameters when running the DOS-based flash utility to "clean" all the BIOS data. But, if you can power off your system, take out the cmos battery from the mobo for a couple of minutes (NOT seconds), replace it again, boot into the BIOS, set "safe" defaults, save and boot again into the BIOS and set the values to what it should be, and "save and exit" the BIOS, then it should be enough to clear all BIOS settings.

Before taking out the cmos battery, you can write down the BIOS settings if you are not sure what they should be.



Using 1TiB size HDD is one of the reasons for HDD manufacturers to update their software tools. So I would suggest, as a general rule, to try using the latest versions, which were updated in their respective websites since UBCD503 was released. You can customize UBCD with those tools.

You can also try different boot options (more "defensive" DOS boot modes, disabling certain drivers during the DOS boot process and so on).



Since HDD manufacturers' utilities are DOS-based tools, may I suggest changing the advanced BIOS settings? You can try disabling Virtualization, x64 settings, special OC settings, and so on. I mean to try this step only after trying the first one I suggested, "cleaning/clearing" the BIOS data/values as I suggested before.

You shouldn't see this message during FreeDOS launch, unless you press-and-hold the Shift or Ctrl key during launch, which make FreeDOS go into some kind of debug mode and print out lots of verbose messages.

This is a very weird problem... Any possibility of swapping the keyboard? I know it's way out, but hey, just a hunch.

Victor, cool, that's a really "revealing" hint. Thanks!
Just happened today that I got two new 1TB drives and wanted to lowlevel format them to see if they've got any problems. I pulled out a rack server that had no drives, put them in, added a DVD drive, burned the latest ES-Tool version and - hit the same problem. It's the same Gigabyte motherboard (but on a different, older, BIOS, I think, I have to check). It became clear that the up and down cursors weren't working in general for this case. And out of curiosity I switched numlock on, and guess what, using the cursor symbols on the numeric pad I was able to cursor up and down and get the format running. Once that is finished for both I can do some more testing.
I remember now that in the past I already had sometimes weird problems in connection with one of the machines. I couldn't get in the BIOS or something like that via KVM, as if it didn't take the keys. I didn't have this problem recently, though.
It appears that this is a unique problem in connection with this mainboard, a KVM (I'm using a KVM to connect to all these PCs) and maybe the way the keyboard is attached.
Sometimes it doesn't get certain keys or gets wrong key codes, like it is apparently the case with the FreeDOS problem.

@bolero,

I am going to propose here some tests that probably you already thought about, so my sincere apologies if these suggestions sound obvious or too basic to mention. But who knows; it has happened before that a too simple configuration/setting was making problems, and was too simple to think about it.

About hardware, you mentioned a specific motherboard (or the same type / model), a keyboard, and a KVM.

About software, you mentioned 2 different CD's, ES-tools by its own, and UBCD.

A way to narrow down the problem could be trying the same keyboard with the same mobo, but with no KVM. Test it with both CD's.

If the problems disappear under that situation, then you don't need to worry about the specific mobo, because under those circumstances most probably the problem would be the KVM.

That doesn't mean that *every* KVM would be problematic.

If that test situation doesn't work, then try changing the specific keyboard with some other ps/2 simple keyboard that you already know it works with no doubts in some other system.

In this situation, do NOT connect the KVM. If, with NO KVM, the new keyboard works with both CD's, then test it *with* the KVM too.

In any test, disconnect any extra additional non-essential devices (no usb devices, for example).

During the tests, try setting the simplest BIOS settings you can. For example, set no special settings in the "power savings" area, no RAID, no AHCI, no OC... Try using the most updated stable BIOS version.

The BIOS includes a "numlock" on/off setting. Try testing your system with both settings.

You probably don't even need any HDD connected to test the system if the problem is related to the keyboard connection (ps/2, usb, kvm).

If you connect a mouse during the tests (with or without the kvm) try using a simple ps/2 mouse (not a usb one).

Until you find the problem by isolation of each hardware component, keep changing the components of the system 1 at a time.

You may discover that the specific mobo has nothing to do with the problems, so you could keep it as your testing mobo as you wanted.

Again, I apologize if all this sounds too basic to even mention it.