Windows 95 support chap skipped a step and sent user into Micro-hell
- Reference: 1712561590
- News link: https://www.theregister.co.uk/2024/04/08/who_me/
- Source link:
Take, for instance, this week's hero, who we will Regomize as "Bill". Many, many years ago Bill toiled in a call center where he offered tech support for the relatively new Windows 95 operating system.
Bill frequently found the best solution for callers’ woes was just to reinstall the OS.
[1]
Of course, the hard drives on PCs of the time were not so capacious as they are nowadays, so the idea of installing a copy of Windows on the disk without removing the previous install was generally out of the question. Just no room. But if a customer was unable to copy their files off the disk, a reinstall of the OS would mean losing their data.
[2]
[3]
Thankfully, Microsoft had provided a utility for just this circumstance, called deltree . What it did was remove the Windows files from the disk, but leave the everything else intact – ready for a fresh installation.
Of course, before you take such a drastic measure, you first run chkdsk – to ensure that the tree you're about to del doesn't have any unwanted branches reaching into places they ought not.
[4]
Everyone knows that, right?
Bill certainly knew that.
But late one afternoon, near the end of a shift, feeling tired and eager to leave, Bill got a call from a user whose Win95 install wouldn't load the GUI. It would get as far as the command line and stall.
[5]You break it, you ... run away and hope somebody else fixes it
[6]DBA made ten years of data disappear with one misplaced parameter
[7]Yes, I did just crash that critical app. And you should thank me for having done so
[8]Intern with superuser access 'promoted' himself to CEO
Fine, thought Bill, this is a job for deltree . So he told the user to run it and waited for the process to finish.
And waited.
[9]
And waited some more.
When the process had taken well longer than it ought to have taken and still not finished, Bill had the caller abort the process and tell him what was there.
Nothing. Nothing was there. Pretty much all of the user's data was gone. Bill surmised that the reason that Windows wouldn't boot to the GUI was that there had been a lot of crosslinked files, so the disk was getting itself into a loop when it tried to load. Thus deltree had wiped everything.
It was exactly the sort of thing that would have been discovered by a chkdsk , which was a regular part of the support process.
But had Bill asked the user to run chkdsk this particular late, tired day? We both know the answer to that, don't we?
Thankfully, Bill had encountered that rare user who kept proper backups, so not much was permanently lost. Bill told Who, Me? the user wasn't even all that upset – given the state of their computer they had anticipated data loss.
A reformat and reinstall later, the customer was back up and running – and Bill was just that little bit wiser.
What's the most important lesson you've ever learned the hard way on the job? Tell us all about it in [10]an email to Who, Me? and we'll share your wisdom for the benefit of other readers.
Note: The old Who, Me? mailbag is very light at the moment, so if you happen to have an anecdote about getting away with your worst moments on the job, we'd love for you to share it. Remember, all names are changed – no-one will ever know it was you . ®
Get our [11]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZhPAPGNYAFNNiIQjz-Gf9wAAAAo&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZhPAPGNYAFNNiIQjz-Gf9wAAAAo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZhPAPGNYAFNNiIQjz-Gf9wAAAAo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZhPAPGNYAFNNiIQjz-Gf9wAAAAo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2024/04/01/who_me/
[6] https://www.theregister.com/2024/03/25/who_me/
[7] https://www.theregister.com/2024/03/18/who_me/
[8] https://www.theregister.com/2024/03/11/who_me/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZhPAPGNYAFNNiIQjz-Gf9wAAAAo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] mailto:whome@theregister.com
[11] https://whitepapers.theregister.com/
Bogus
I'm surprised such an entirely bogus story slipped through El Reg's expert hands!
First, deltree does not 'delete the windows system'; it will delete ANY subdirectory tree you *tell it to delete*.
Second, chkdsk doesn't mystically identify 'important data' you may want to keep; rather, it checks the entire filesystem *integrity*, and identifies and may try to repair any *corrupted or truncated* files. It's the DOS equivalent of fsck really.
Re: Bogus
I'm willing to chalk that up to a slip on the author's part.
We have two main issues - the first is that the person telling it isn't a journalist so may not be phrasing things well, and Matthew JC Powell has to deal with that.
The second is that this was somewhere between 29 to 24 years ago, and therefore the memory may be a touch hazy.
It's good to have high standards, but I find these minor mistakes fairly easy to forgive in these circumstances.
Re: Bogus
C:\> chkstry /y
Checking story on R:
The type of sory is HISTORIC
CHKSTRY is verifying overall integrity (Stage 1)...
Found basic structure.
Integrity verification complete.
CHKSTRY is verifying details (Stage 2)...
Possible inconsistent use of DELTREE.
Possible inconsistent use of CHKDSK.
CHKSTRY is verifying indexes (Stage 5)...
CHKSTRY has scanned the story and found minor issues.
You may continue to enjoy The Register however you should run
CHKSTRY with the /f option to fix any errors found.
3373 Total characters
625 Total words
21 Total paragraphs
C:\>
Re: Bogus
From memory (and a quick Google), deltree was released in MS-DOS 6 and retained through Win 9x. But yes, a chkdsk first would definitely be in order.
Re: Bogus
Something similar to what is described could be a misremembered scenario. As you say, deltree deletes everything under the specific directory so deltree c:\windows would do a reasonable job of removing windows. However as a dos utility it wouldn't follow windows shortcuts and would instead delete them, and windows didnt support real links so I can't see a scenario where it would escape from the windows directory and delete the whole disk. Chckdisk would help clean up lost sectors and mismatches between the FAT and what is on the disk, but would not do anything clever with directory trees.
Most likely to cause the described behaviours would be if the person ran deltree c:\ instead of c:\windows
Scandisk?
Having worked in a call centre near Sidcup* that handled Microsoft's newly outsourced OS support in 1995, I have one question...
Why not scandisk? Easier to use, does most things better, and has one huge advantage... the surface scan.
The integrity check of the filesystem's structure will take a couple of minutes, but then you're into a nice long scanning operation.
Which gives you the excuse to wait five minutes for them to realise that this will take forever, and then tell them to call back if it encounters issues. Allowing you to go home on time.
See? It may be almost thirty years ago, but I still have my support skills. ;-)
---
* Any other FCY03 survivors out there? FCY01 is a housing association office, 02 and 03 are now flats. The Seven Stars is still open, and I'm tempted to swing by one day for old time's sake...
Windows can also break Windows
A long time ago when I did 1st line support I was remotely removing some old profiles on a Windows 2000 workstation to free up disk space for the user when the machine decided to also delete the profile of that same logged in user. I hadn't selected that profile for deletion but all the desktop icons disappeared before an error popped up saying some files were locked. After a quick check to confirm this I called over my supervisor who took one look then said, "What the f..?"
We passed the call over to the technical team who were eventually able to recover any of the users data which had been deleted, but they confirmed that I hadn't done anything wrong but that they suspected there was some corruption within one of the profiles which had caused the issue. They'd also never seen this happen before.
Don't follow the instructions
One of my first jobs ( 40+ years ago) was working with DOS/VS running under VM on the mainframe. You had one disk for the system, and one disk for the user data. My job was to recompile everything and put it on the user disk. We had two user disks, and would flip/flip between build and other people using it.
Day 1, I followed the instructions, erased all the files on the user disk and started building.
Half an hour later someone wandered round saying is there a problem with...
The instructions had said link in disk xyx... so I did, and wiped out the current disk.
My supervisor said (face palm moment) that is an example of the command - not the actual command.
The documentation was changed to make it clearer
Day 2, I followed the new instructions.
Half an hour later people came round and said... is there a problem with....
The problem was that an old disk was "lying around" and the system used that in preference to the one I was trying to use.
The documentation was then changed to 1) remove all user disks from the configuration, 2) link in disk
Day 3 I was moved to a different project.
Re: Don't follow the instructions
Sounds like you had the perfect start for an illustrious job on the Tiger Team.
Windows 95...
" Absolutely ghastly. Just don't even talk about it ." *
Then being on the Unix side of the loony line I only had a nodding acquaintance with W95 but I think it still used a FAT file system and that chkdsk would be used to detect cross linked clusters.
The FAT is basically a linear linked list of fixed sized clusters (of contiguous sectors) with the index of the list head stored in file's directory entry - like a very poor inode implementation. If the indices in one file's linked list get scrambled with another file's (or directory's) cluster list bad things happen.
Think a unix subdirectory ("/home/simon/bad") ☆ hard linked to "/" and "rm -rf /home/simon".
Precambrian Unix lacking mkdir(2), used mknod(2) to create a directory and using link(2) to enter ".." and "." - both restricted to root. /bin/mkdir was suid root I think. I think as late as SunOS 4.x hard linking directories was still possible with "/usr/etc/link."
* HHGTTG
☆ If the BOFH were clearing his desk I would be quickly heading to the airport...
Still one of the best ways to fix Windows.
I recently had Windows refuse to boot and it was giving all sorts of errors about how the boot information is corrupt. Now this should be an east fix with a Windows install USB and running "Bootrec /RebuildBcd" or various other similar commands in the command prompt, but none of that was working as it was saying I didn't have permissions, which is odd as the installer should be running as admin.
Then some guy in the comments of the microsoft support forum said to ignore all that and just tell the installer to blind dump the boot files at the start of the disk, and gave a command to do so. Boom, Windows booted back up.