#148 Out of memory loading STRINGS
I needed to flay a new BIOS for a Dell XPS 15 9530 laptop that is installed with Ubuntu 14.04. So I downloaded the BIOS exe file from Dell, then I created a bootable USB stick using unetbootin as explained in the first anser on the page http://askubuntu.com/questions/46886/how-to-create-a-bootable-usb-stick-to-flash-a-bios
So unetbootin installed on the USB stick the version 1.0 of FreeDOS. Then I copied the BIOS exe file in the root of the USB stick and booted from it and used the option "Load FreeDOS without drivers". Then I changed the drive to C: and launched the BIOS exe file. Here is the output:
… Verifying flash… done Verifying Boot Block… done - Writing EC Flash…… done - Flash completely !!! successful! [Out of memory loading STRINGS.] Failed to load the strings resource into memory, the location pointed to in %COMSPEC% seems to be invalid. Please specify another location of FreeCOM to try to load the strings from, eg.: C:\COMMAND.COM or just hit the enter to cancel to load the strings
At that point the keyboard was dead. After waiting for a while (many minutes) I tried the power button and that did not have any effect (no matter how long I kept it pressed). I waited again many minutes and then I unplugged the power cable and the laptop shut down. Luckly the laptop booted afterwards and the BIOS seemed updated (it reports the new expected version), however I am not entirely sure if the "successful" message meant that the the entire flash process was OK, or just the EC Flash step (and other subsequent flashing steps IF ANY for other BIOS parts did not happen anymore...)!
The point here is that such errors CANNOT BE TOLERATED when flashing BIOS! I would certainly not try to use again in future FreeDOS to flash a BIOS after this experience!
This is a shell error, most likely, although the shell hasn't changed much, if at all, since FD 1.0 (2006). What does "ver /r" say? Are you using FreeCOM 0.84-pre2 XMS_Swap or older 0.82pl3? Does putting "/MSG" in the SHELL line of CONFIG.SYS make that error go away?
At minimum, you should definitely only be using FD 1.1 (circa 2012):
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/
(Although FD 1.2 is in beta, so if you want to try the previews, get on the mailing list.)
There are several commercial DOSes that you can use instead, but I don't think that's your problem here. (Unlike FreeDOS, they are not free, so you will have to pay.)
Even though FreeCOM is the preferred choice for shell, there are other alternatives, so you can use one of those in a pinch (if that is your problem here, if it can't be fixed otherwise).
1). http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/contrib/
2). http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/4dos/
But I suggest you use a different method other than UNetBootIn, if the above suggestions don't improve things:
1). http://rufus.akeo.ie/
2). http://joelinoff.com/blog/?p=431
3). https://wiki.debian.org/FlashBIOS
Hi Anthony,
Just to make sure, when you say that "This is a shell error, most likely", do you mean that the out of memory happened in the shell AFTER the flashing program finished, which would concur once more to deciding that the flash process was OK?
I am asking this because I am trying to ensure once more that indeed the whole flashing process was completed OK.
Thank you.
According to your own output, that's what it seems to imply.
Again, I recommend that you boot up again (putting /MSG somewhere in your SHELL line in CONFIG.SYS) and try re-flashing, if you're that worried.
Just for example, here's a line from one of my (virtual) machines:
!SHELL=\SYSTEM\COMMAND.COM \SYSTEM /E:1024 /MSG /P=\FDAUTO.BAT
Hi Antony,
Thanks for your answer.
I only needed FreeDos for flashing BIOS. However given the error that I got, I do not dare to use again FreeDos to do any other flashing in future, becasue the risk of bricking the laptop because of such errors is not a risk that I am willing to take. So, when I will need to flash again a BIOS on any laptop in future I will certainly not use anymore FreeDos. See, the very point here is that the flashing process is so important to perform without any errors that I cannot possibly put that at risk by using FreeDos again. So I am done with using FreeDos. I just raised the bug here in order to make other people and the developers aware of this problem. Sorry that I cannot help more.
Thank you.
You should be asking Dell customer support directly for assistance, presuming you still have a valid warranty. Visiting third-party sites is always a gamble (especially ones that suggest old versions). Presumably they know exactly what advice to give you on how to make a bootable medium for re-flashing your machine. There is no need to fear if you follow their advice exactly.
If you are worried about messing things up, then don't flash it at all (unless something is broken otherwise). Or get a professional to do it.
Without further testing, this report is not very useful. It could be any number of things, in combination, not just a minor FreeDOS shell bug. But here you don't even need a shell barely at all, and DOS is hardly doing much. Even though it's a copout for us, Dell needs to be more specific on how users are expected to update their own firmware. If they don't test with FreeDOS, then you should only use whatever they recommend. Besides, that website is from 2011, recommending an old release from 2006, while latest 1.1 is from 2012 (and 1.2 coming soon). So any bugs in older, unmaintained releases will probably not get fixed, especially without further testing.
A quick search finds two relevant pages (one leading to the other):
1). http://www.dell.com/support/home/us/en/19/product-support/product/xps-15-9530/drivers/advanced
2). http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=D54FM&fileId=3475859161&osCode=WB64A&productCode=xps-15-9530&languageCode=en&categoryId=BI
Apparently 9530A09.EXE (6.87 MB) is from 04 Aug 2015 (version A09).
Did it not come with Windows? Did you wipe it and reinstall? Because Dell claims this:
But I still think you need to ask Dell directly for further assistance.
I've just had exactly the same thing happen. Again, a Dell XPS 15 9530. Pulled the power cable and it powered off. On restart BIOS had successfully updated from A08 to A09. I'd PXE booted into a boot floppy image from FD12FLOPPY.zip.
I can't believe that both of us having problems with exactly the same system is a co-incidence.
I have seen a lot of problems with BIOS updates. Sometimes the producer of the computer added a not working batch file (wrong options, wrong name of flash tool etc!). At a DELL Latitude D531 the latest BIOS (A12) exe version did not work at all (all others before had no problems), I just tried to enter the service tag for this older laptop (ca. 2010) and the service assist says that it does not find the tag, but A12 can be downloaded from another DELL subsite, two years ago it said that it is out of support time - finish...
In former times it was sometimes even possible to update an absolutely wrong BIOS file, but now first the checksum is checked.
Nowadays most modern devices offer a BIOS update without the need of a bootdiskette,
you simply have to add an USB-stick with the BIOS file, run BIOS with DEL or F2 , look for update the BIOS and update it from within the running BIOS.
Gigabyte now even offers the update of a destroyed first BIOS via an USB port that has a white marker, the explanation in the manual is a little hard to find and understand, but it works.
I guess that the problem was not FreeDOS but a bug in the Ubuntu description. Messages like you reported often appear, if the config.sys is not set or the mentioned command is not in config.sys.
!SHELL=\SYSTEM\COMMAND.COM \SYSTEM /E:1024 /MSG /P=\FDAUTO.BAT
maybe /P= was missing which makes it permanent? Maybe there was too less usable RAM?
Can this thread be closed as it will be hard to find the final reason?