[jaclaz]

Dave-H

Don't take it the wrong way, but more than 6 Mb of system Registry means to me that it's still bloated (NTREGOPT only defrags Registry, does not clean it).

If you have a safe, tested way to dual booting, you should run (like ANYONE should do) ERUNT to make a safe backup of the Registry.

Then run against it any known Registry utility known to human kind.

I would start (for Free) with this one:
http://www.hoverdesk.net/freeware.htm

never let me down in many years.

More here:
http://www.msfn.org/board/Registry-Cleaner...son-t68677.html

jaclaz

[Dave-H]

Not taken the wrong way at all jaclaz!

I'm well aware now that my registry is a lot bigger than it should ideally be, the question is why.

I have a history of registry size problems on Windows 98, which has only recently been resolved (see the "Puzzling Registry Size Issue" thread over on the Windows 98 forum) so I am well aware of registry cleaning and optimisation programs!

In fact I already use Regseeker regularly on Windows 98, but haven't tried it on Windows 2000.
I do use Wise Registry Cleaner on both OSs, and clean out all the redundant MRU information etc.
I'm not sure about system configuration data though. Wise does check for invalid CLSIDs, but I'm not sure about invalid/obsolete hardware information. I do have another invalid CLSID checker which I have run too, but it didn't find much wrong.

I do have an excellent system information utility that came with the HP software for my HP printer.
That will list all the hardware device information in the registry and allow you to delete obsolete items.
Anything that's not actually physically connected to the machine when it scans is shown with a yellow mark.
I often delete them all, and as it's usually USB stuff, the system just puts them back if I subsequently reconnect the device(s) in the future.

Unfortunately, having done all this, there never seems to be any big reduction in the size of the registry files, even after running the optimiser, which should remove any empty space.
As I said, I have removed one of the ControlSets, which was marked as a "failed" one.
That did produce a big drop in the SYSTEM file size, from over 9MB to its present size of 6.2MB.
Good, but still not enough!

I don't seem to be able to permanently delete any of the other ControlSets, as they all seem to be necessary and just get put back. I have CurrentControlSet, ControlSet01 which is the default, and ControlSet02 which is the "Last Good".

I do back up my registry regularly. I totally agree that this is good practice anyway. I generally just use the backup feature in MSBackup, which is part of the routine to make a startup disk.
Wise Registry Cleaner also has a backup facility for the whole registry, and I use that too after I've cleaned it.

Is there anywhere I should be looking in the registry where a large chunk of unnecessary data might be sitting that the scanners aren't finding?

[jaclaz]

My crystall ball being again to the shop for tuning , I cannot say.

I used:

Quote

any known Registry utility known to human kind.

exactly to avoid meaning "use ONLY Wise Registry Cleaner" (or any other single app).

Each app, besides a few simply not up-to-the-standard, has different ways to "look" at the Registry, and even a "very good" one may overlook, for any reason, what another finds and fixes in no time.

jaclaz

[Dave-H]

jaclaz, on Mar 2 2009, 02:37 PM, said:

My crystall ball being again to the shop for tuning , I cannot say.

LOL!

jaclaz, on Mar 2 2009, 02:37 PM, said:

I used:

Quote

any known Registry utility known to human kind.

exactly to avoid meaning "use ONLY Wise Registry Cleaner" (or any other single app).

Each app, besides a few simply not up-to-the-standard, has different ways to "look" at the Registry, and even a "very good" one may overlook, for any reason, what another finds and fixes in no time.
jaclaz

Point taken!
I will try running the others on Windows 2000 when I get home!
I'll let you know the results......

[Dave-H]

Well, now I am at home!

I hit the registry with Regseeker, which found over 1000 errors, and an OLE Cleaner program which found over 200 errors! All well and good.
The list was so long on Regseeker that I didn't study it all, just took out a few entries I spotted that I knew needed to be ignored. I then let it repair all the rest.
I let the OLE Cleaner repair everything it found.
I then ran the registry optimiser.

On reboot, I got several error messages, mainly relating to services being unable to start.
I also had nothing at all in the right hand panes of Windows Explorer, which was rather worrying!


The registry cleaners had obviously been a bit over-enthusiastic!
Fortunately, I had of course made a backup.


I went into Windows 98 to look at the registry files' size, which I hadn't been able to do as Explorer wasn't working properly in Windows 2000!
I was a bit disappointed to find that the size of the files hadn't actually changed all that much.
The SYSTEM file had been 6.2MB, which had reduced to 6.07MB after I had removed the hardware device information for the unconnected devices.
It had now reduced a bit more, but only to 5.18MB, nowhere near enough!

Anyway, I restored the backup, and everything was back as before.
What next I wonder..........

[antoineL]

jaclaz, on Feb 21 2009, 12:38 PM, said:

Ascii2, on Feb 17 2009, 11:57 PM, said:

jaclaz, on Feb 17 2009, 01:25 PM, said:

Ascii2, on Feb 17 2009, 07:19 PM, said:

(not Windows Server 2003, as it seems to use a different file to load the operating system)

This is news to me.
Care to expand on this?

Windows Server 2003 products may use a boot loader file named "Osloader.ntd" (NTLDR and NTDETECT.COM may still exist). I am uncertain between the relationship between the different boot loaders of Windows Server 2003.

Well, Osloader.ntd is ONLY used when booting from ADS:
http://support.micro...kb/843536/en-us

Probably just like SETUPLDR.EX_ is used instead of SETUPLDR.BIN for PXE/RIS installs/PE's.

Close. In fact, you should compare it with OSLOADER.EXE, which is (as Jaclaz already knows is the second part of NTLDR (the first one being the StartUp module which brings the computer into 32-bit mode).
So if you compare them, you'll find they are extremely similar, they even have the same .PDB referenced; the only differences are in the PE header:

• there is a supplementary section, named .detect
  
• the ImageSize is bigger
  
• the checksum are different (better have to, since they are checked )

Now, if you consider the extra baggage at the end of OSLOADER.NTD, it is around 46 KB, and it is... NTDETECT.COM

So I believe it works this way: PXE ROM, STARTROM.xxx sent with TFTP, asks for "NTLDR" but expects a .EXE (this is standard behaviour of Microsoft's PXE infrastructure), the server sends this OSLOADER.NTD packaged as a single file and the OsLoader works alone, without need to download a further NTDETECT.COM later.

What I do not understand yet is how OsLoader does to "know" it should either load_from_disk/ask_via_tftp for NTDETECT.COM (normal case), or just have a look in memory behind itself (osloader.ntd case). The evident way to do it (just inspect the COFF header) is not that evident, since I did not see any reference to ".detect" in the binary; perhaps it does that by direct inspection to entry #12, without checking the name?

OK, next stage is to build some frankenboot, i.e. paste StartUp and OsLoader.ntd as NTLDR, removing NTDETECT.COM and see if it works...
Another try is to "append" ntdetect.com to setupldr.bin (or renamed version of it, like cmldr ) and see if Setup is able to boot without needing the ntdetect.com extra baggage...


PS: I am a newbie here, so if this should be redirected to another thread (or a new one), please do; also I'd appreciate pointers to similar researches already done about OsLoader.NTD.

[jaclaz]

antoineL, on Mar 18 2009, 05:09 PM, said:

OK, next stage is to build some frankenboot, i.e. paste StartUp and OsLoader.ntd as NTLDR, removing NTDETECT.COM and see if it works...
Another try is to "append" ntdetect.com to setupldr.bin (or renamed version of it, like cmldr ) and see if Setup is able to boot without needing the ntdetect.com extra baggage...

And what about prepending to OSLOADER.NTD just the first part of NTLDR/SETUPLDR.BIN and see if one can get rid of NTDETECT.COM?

Checksum will need to be corrected/bypassed, of course.

jaclaz

[colguetti]

I know it´s a little off-topic, but I´m curious about the NTLDR part of this thread, I know that the Longhorn Beta 1 can be used on Windows XP, a cool side effect is that the Longhorn Beta 1 NTLDR has HAL and Kernel Autodetection, I wonder if this stuff works on windows 2000, in fact, I´ve opened a new topic about it, please let me hear opinions !!!!

Regards to everyone !!!

[Dagwood]

Interesting topic! I carried out my own tests, preparing four installation CDs with the following NTDETECT and NTLDR files- with stock W2000 SP4 files, with XP SP3 files, with Server 2003 files and with Server 2003 SP2 files. Basic specs of test PC- Asus A8V-X MB, single-core Athlon 64 3800+ CPU, nVidia 7600GS vid card, old 10 GB Quantum Fireball Plus HDD, 4 GB DDR-400 RAM (curiously, system only sees 2.9 GB, even with x64 OS- still haven't solved this one). The HDD was wiped with DBAN before installing the OS, which was then updated with MB and vid drivers plus all W2000 updates. After every test the HDD was wiped before installing the next setup to minimize the chances of software remains from previous install influencing results. Each install was started 5 times and boot time measured.
Boot times from start boot to appearance of login window were as follows-

With stock W2000 SP4 NTDETECT and NTLDR files time required was 48 seconds.
With XP SP3 NTDETECT and NTLDR files time required was 46 seconds.
With stock Server 2003 NT DETECT and NTLDR files time required was 44 seconds.
With Server 2003 SP2 NTDETECT and NTLDR files time required was 48 seconds (which suggests that Server 2003 SP2 installations MIGHT benefit by reverting to the original Server 2003 files!!! This is progress????).

While a crude test it does suggest that the Server 2003 files are the best replacement for the stock W2000 SP4 files. A different PC spec may give different results, though. And while not a spectacular improvement, 4 seconds are not to be sneezed at.

This post has been edited by Dagwood: 19 November 2010 - 03:26 AM