re: XP Install Missing Files: Correct Fix
Sunday, January 9, 2005 at 3:24 am
Windows XP Annoyances Discussion Forum
Posted by scott
(1 messages posted)
I can confirm this theory. I just in stalled some faster memory into an older machine
and it is the first time i have ever seen this with this cd. it has always worked
in the past. -scott
On Wednesday, October 27, 2004 at 12:58 am, Nesmira wrote:
>Alright, I got done reading all your posts and I'm afraid that none solved the issue.
>
>Now, let me clear up some of the confusion going on.
>
>First issue is the CD file structure. It does NOT matter
>which ISO9660 format you use as long as it remains ISO9660. None of the critical
>install files are truncated. example: driver1~.cab
>
>That is why on the REAL XP install CDs, you will see files LONGER THAN 8 characters!!!
> A good example so you see I am not lying is to check out the XP image in the
>color="blue">DOCS folder. If you already modified the original install files
>by using DOS 8:3 filename, you will see a truncated file. That original file name
>is in FACT:
>winXP_logo_horiz_sm.gif
>
>That image is referenced in the original README.HTM placed
>at the root of the CD. So that blows away the whole DOS 8:3 theory.
>
>Second, DO NOT rename files. example.dll is NOT the same
>as example.dl_. The reason is because alot of these files are placed into windows
>CAB files and the "_" underscore seperates them for indexing. If you clearly look
>at your system32 folder
>you will notice the lack of underscores. When missing a file (namely a DLL) windows
>replaces the file from the custom CABs it created during installation and renames
>it without the underscore. It does this to protect the integrity of the operating
>system and to also limit the files neccessary in the directory. You ask: Why wouldn't
>they just keep everything in a CAB from the start? Here's why. Install would take
>forever. Remember, not all computers are the same, and that's why there are drivers
>too. Hardware specific reasons. I'm not going into detail on that. You get the
>idea.
>
>It is NOT the speed which you burn CD's, the type of media
>(well, maybe...if you buy really really cheap crap) or so called "Weak sectors".
> How can a sector be weak? Either you can read it, or not. There is a difference
>between being dirty or scratched or old cd readers to be dirty. It is possible however
>to have bad files from damaged media. Of course, there are too many people with
>the same problem for us all to have bad files. Even someone else who posted that
>they got Corporate XP discs with the Microsoft Hologram on them.
>
>This is NOT a pirated version issue either. Microsoft
did
>NOT get smart overnight and suddenly stumble across a way to trick us. It is ALL
>based on pure logic, not conspiracy.
>
>If you are still stubborn about the ISO argument. Go here and learn: http://en.wikipedia.org/wiki/ISO_9660.
>The install files are not longer than 8:3 anyway.
>
>Now that all the rubbish is taken care of, lets get to the REAL resolution.
>
>Microsoft published an article which was somewhat more realistic. You can find this
>article here:
>Random Files May Not Be Copied During Text:Mode Setup
>http://support.microsoft.com/?kbid=257954
>
>Indeed, the files are certainly random. They change from person to person, disc
to
>disc, machine to different machine. Different files missing? Different machines?
> Yup, I believe this is a hardware issue. Perhaps performance reasons. I know
from
>my own experience, I have not seen this on newer machines, not to say that it doesn't
>happen. In the microsoft article they mention bus speeds. 100MHz and 133MHz particularly.
> All the machines I have come across that did this were specifically 100MHz or 133MHz
>bus speeds.
>
>This issue would normally be closed at this point, however this happens on machines
>meant for 133MHz bus speed and installed with 133MHz memory and CPUs. The same goes
>for 100MHz systems.
>
>For all those CompTIA A+ techs out there, this should make some sense. Lets say
>you are copying a file.
>Step 1. The program needs to copy a file.
>Step 2. The program utilizes the kernel in memory and passes the command to the
processor.
>Step 3. The processor processes the command and says (in laymans language) ok, I
>need to tell the CD-ROM to retrieve this file and send it to memory which I will
>then copy to the hard drive.
>
>Simple right?
>
>So if all goes well, Mr. CPU reads the disc, finds the file, and routes the appropriate
>data through the chipset to memory. From there, the CPU gives the command to retrieve
>data from memory and now route back through the chipset to disk. ALL DATA MUST
BE
>PROCESSED AND SENT TO MEMORY!!! This is the basics of hardware and data processing.
>
>Now, all these processes are based on time. Your memory has a time to it. It's
>called a cycle, and measured in MHz. Hypothetically, your system bus is as fast
>as the slowest component will permit. Now, lets say the memory is faster than the
>bus. Microsoft is correct in the idea that the hardware was not limiting the correct
>cycle time.
>
>In this theory, since the memory has a faster cycle, it would report information
>too fast and incomplete to the CPU's normal bus reading speed and miss data chunks
>to report that the data is corrupt (not in order). Or missing like the error message
>you all get. Corruption is inability to read from the source. However the error
>message does not tell you "Cannot read file from disc". It simply says, "File is
>corrupt or missing". The program does not distinguish the difference between corrupt
>or missing. We know for a FACT that it is NOT missing. Since this happens randomly
>on machines for different files, we know it can't be corrupt files. Corruption also
>happens when memory modules are bad, but then again, we can't all have bad memory.
>
>So here we are back to the same problem. Random errors. Random to you maybe, but
>not the computer. :-)
>
>A reasonable explanation is that the cycle time in memory can appear to make data
>incomplete and corrupt since the CPU checks the CDROM again to see if the data is
>intact during its transfer to memory. If memory does not match the data on disc,
>it is corrupt and not passed to Hard disk.
>
>Depending on the data order being copied vs. your bus speed will be your corrupt
>or missing files. The larger the gap, the more the missing or corrupt files. It's
>a detailed mathematical equation based on time.
>
>If you still didn't get that, pretend you are playing baseball(transfering files).
> And the pitcher(memory) throws 5 balls(data) at once for you(the CPU) to catch.
> Are you going to catch every single one? Didn't think so.
>
>Now, this is a test. I am not for certain it will work. But, I have exhausted
and
>eliminated all the other possibilities. I will be testing this tonight and try
a
>variety of solutions. From memory performance, to size, to quantity and quality
>of memory sticks. I hope it works and I will report all findings back to this forum.
> Sorry for the long post, but this problem has got to be resolved.
>
>Thanks for reading!!!
>-Nesmira
|
All messages in this thread [show all]
 |  | |  | re: XP Install Missing Files: Correct Fix (scott: Sun, Jan 9, 2005, 3:24 am) |
| |
| |
| |
Return to the Windows XP Discussion Forum
|
|
