jaclaz

Quite evidently they are similar enough for this scope (in this context). jaclaz

#1. and #2. are "as expected", as said, it is not "normal" (but if it is a choice of yours, it is good of course ) to have the Boot and System volumes on two different disk drives, it would make more sense to have the first disk (the one with C: and E:, both the "original" and the "clone") to be self-standing, this would also allow to clear DosDevices in the Registry, should the issue be connected with the Disk Signature (the fact that when you had both the "original" and the "clone" connected the "clone" was put offline should mean that the signatures are the same, but you never know). At the time you had both the "original" and the "clone" connected, did you see in Disk Management a message *like* this one? Personally I would run a BCDBOOT command and have the BOOTMGR and \boot\BCD on the C: volume, but as long as you have both disks connected the thing should work. I would also check the disk signatures of the "original" and of the "clone" disks, but the "flickering" in case #3. above is not a "common" symptom, it may still mean that the clone was not successful, i.e. that some file(s) on the "cloned" C: volume is/are corrupted. Problem is that it won't be easy to find that/those files . Can you try (with "cloned" C: and E: and "cloned " D: only) the other options (pressing F8 when it boots up)? Try both "Safe mode with command prompt" and "Enable boot logging", maybe the PC boots or at least shows where the issue might be. Otherwise you can try to "repair" the "cloned" C:, do you have a suitable Windows 7 install DVD? To check the disk signatures (just in case), you could use as well a PE (the one in boot.wim on the install DVD should do) and diskpart (detail disk will output disk ID, and 7 if I recall correctly has also the uniqueid command). jaclaz

I don't get it. This is what I just posted a link to, it has already been done some 8 years ago. Still, it remains an unsupported, not entirely "stable" or particularly "tested" on many machines. jaclaz

NewFileTime: http://www.softwareok.com/?seite=Microsoft/NewFileTime (up to 2.71) is explicitly Win98 compatible: https://web.archive.org/web/20161130142021/http://www.softwareok.com/?seite=Microsoft/NewFileTime BUT the SAME version page has been later changed with Win9x not mentioned anymore https://web.archive.org/web/20170120060612/http://www.softwareok.com/?seite=Microsoft/NewFileTime Maybe even the current version is still 98 compatible unless of course in the course of making it working in Windows 10 they ruined it. jaclaz

Well, just for the record a related thread with some actual info for the Registry needed modification and the patch to NTLDR (reboot.pro is half down right now) via Wayback Machine: https://web.archive.org/web/20170324081949/http://reboot.pro/topic/9474-busting-the-myth-about-ramdisksys-xp2003/ but WinvBlock is still a "better" solution IMHO. To have a "tamper proof" system is also possible to use the ETBOOT project, and run XP from CD (JFYI): https://web.archive.org/web/20170224121218/http://reboot.pro/topic/3890-project-etboot/ https://web.archive.org/web/20150401052002/http://erwan.labalec.fr/ETBoot/ jaclaz

No need to open a new thread, it is the same (actually continuation of) issue as this one: jaclaz

To understand what is happening, I need to know what happens if you do the experiment with just the Disk 0 attached (the original "first" disk, the one that has volumes C: and E: in your screenshot). jaclaz

Well, you can stamp your feet and cry as much as you want, but in the posted screenshot the D: drive is marked as "System" so it is part of the booting. Try doing the experiment suggested, the OS shouldn't boot with just Disk 0 connected as - at least when you booted it to take the Disk Manager screenshot, the D: (Disk 1) was involved. jaclaz.

Back in time: http://web.archive.org/web/20071219023529/http://webplaza.pt.lu/public/rpetges/download/download.html ac530.exe was just ac.exe: http://web.archive.org/web/20071219023529/http://webplaza.pt.lu/public/rpetges/download/ac.exe jaclaz

Here (via WaybackMachine): http://web.archive.org/web/20150715000000*/http://www.virtualltek.com/data/downloads/nlaom21.exe jaclaz

OK. Though something is still not as you described before. DIsk 0 (original) is 1 Tb. Disk 1 (original) is 250 Gb or so (not 500) Disk 2 is the "clone" of disk 1, and it is 500 Gb, not 1 Tb (and the single partition in it has been enlarged from 232,88 to 465.76) Disk 3 is the "clone" of disk 0 (and it is now offline most probably because of a disk signature conflict). The disk 3 can be put "online" by changing (temporarily) the Disk Signature (if it is conflicting and the diks has been put automatically offline), but for the moment it is OK, it seems like the "cloning" at least made the partitions correctly. The 450 Mb (Recovery) and the 638.54 Gb partitions (presumably "Data") should not be involved in the booting at all. In theory the disk 1 and 2 as well should have nothing connected to booting, normally, BUT you seem like having a "mixed approach". The disk 0, partition 1 volume "C:" in the screenshot has the characteristics: Boot, Pagefile, Active Crashdump, Primary partition The disk 1, partition 1 volume "D:" in the screenshot has the characteristics: System, Active, Primary partition Normally (when there is not a reserved small hidden partition for the boot files) a single volume is at the same time Boot and System. The good MS guys have these attributes "reversed" , Boot means that the volume contains the System (in practice C:\Windows\), while System means that it contains the boot files (in practice BOOTMGR and \boot\BCD), see: http://www.multibooters.co.uk/system.html So it seems like your original boot process is: BIOS->Disk1,1(D:)->BOOTMGR->\Boot\BCD->Disk 0,1 (C:)->C:\Windows\System32\WINLOAD.EXE->Windows Normally the 0x000000CF BSOD means that the \boot\BCD cannot be read, so it seems like the issue is actually on disk 2 (the "clone" of disk 1). You can easily verify if this is the case, by removing all disks but disk 0 and attempt booting. (it should NOT boot) and give you a missing BOOTMGR error Then try adding disk 1. (it should boot as before). Then try removing disks 0 and 1 and add only disk 3 (it should NOT boot) as with just disk 0 connected. Then try adding only disk 1 (yes disk 1). What happens? As a side note (not necessarily connected to the issue) since right now you have both Disk 1 and disk 2 "online" it should mean that in the process -somehow- the disk signatures of them were made different. jaclaz

And - to be fair to the good MS guys - some of the requests/reports may well be exaggerated, and - just as an example - the fact that Geek Squad could not restore operation of the computer and a new one was needed is not proof of anything, actually WHEN someone will report that Geek Squad did actually fixed properly *anything* THEN it will be IMHO worth the news . If the point is that the whole "upgrade" process was done in a reckless and irresponsible way, it has however a lot of merits. jaclaz

Well, we all saw this coming ...: https://arstechnica.com/tech-policy/2017/03/unhappy-windows-10-upgraders-take-microsoft-to-court-for-lost-data-damaged-pcs/ jaclaz

Basically (for the one or the other reason) you didn't actually "clone" the disk(s). Contrary of what most people think (and due to the misleading name) Clonezilla very rarely can provide an actual "clone" (as long as we define "clone" an identical copy). The fact that the copies created by Clonezilla (when used properly) are in most cases "good enough" is another thing. Your report is confusing, you talk of the one or the other disk, mixing liberally drive letters (that have no real meaning when talking of disks, since they are - unless some special provisions taken - assigned automatically by the OS depending on an algorithm based on enumeration). What you need to do is to describe (properly) the situation before AND the EXACT way you attempted to clone the original disks. Ideally you should re-connect the original disks as they were and take a snapshot of what you can see in Disk Management (or enumerate disks, partitions and volumes in diskpart). Then do the same with the new sets of disks. Most probably the issue here (since you suspect that there were some bad sectors) is that there are some bad sectors and as such some data in them was not transferred correctly to the "new" disks BUT the difference in drive lettering could mean that )for whatever reasons) you (or Clonezilla or both) missed a partition altogether, as the drive letters are "shifted by one". CHKDISK can often correct minor errors, but it cannot obviously do miracles. Additionally, if you have two hard disks and one of them is developing bad sectors, it doesn't mean that the other will also develop them soon, so there is no real reason to clone the disk that has no bad sectors and what is needed for the one developing bad sectors is not a "clone" (as intended by Clonezilla or similar) but a proper, byte-by-byte, sector-by-sector forensic sound clone, that will most probably anyway need to be analyzed and "fixed" (if possible) and/or data recovered and re-deployed to the new disk (without any actual need for it to be a "clone". You had ORiginally two disks, let us call them OR1 and OR2, which one of them is the WD 1 Tb and which one of the two is the Samsung 500 GB? Which partitions/volumes (drive letters) were on each of them? Which one was the disk where the OS was installed? Was that a "from new" Windows 7 install (thus probably having a 100 or 200 Mb "hidden" partition with the bootfiles) or a more traditional install with the BOTOMGR and \boot\BCD on the C:\ drive (or something else)? jaclaz

Which is good , All's Well That Ends Well, or maybe Much Ado About Nothing. Definitely the Immortal Bard wrote good titles (besides the plays themselves) but I was expecting something more along the lines of Sir Arthur Conan Doyle ... jaclaz

Hmmm, the plot thickens ... jaclaz

Well, to be fair, Dybia replied with some wrong info (78 as opposed to 7B, which should be actually 0x0000007b) and never replied properly when i raised the doubt about that piece of info. No need to be sorry, it's OK , it happens everyday in life, sometimes you win (some respect) sometimes you lose it . jaclaz

Some news on telemetry we have now at least some data (hoiw much reliable it's a whole different thing): https://www.theregister.co.uk/2017/04/06/microsoft_windows_10_creators_update/ jaclaz

For the loopback test you don't even need a hard disk, what has the presence or not of the card under the PCB to do with it? The loopback test is made by connecting the Rx and Tx together and sending some data to the (virtual) COM port and see if these data is echoed back correctly in terminal, to make sure that the adapter and the setup is correct BEFORE even touching the hard disk. It is a rare occasion (but it can happen) that the adapter is simply not working (DOA or Dead On Arrival), and as well even if the setup is usually very simple, it can happen that the device driver or however *soomething* in the OS is improperly set and makes it not functional. In your profile you state you are using a Windows 10, mybe that is part of the problem, ideally these instructions are (were) intended for a computer running XP (that has somehow a more direct/less complicated access to hardware) though it has also been used successfully with 7 (using a Terminal tool and - I believe - with no UAC and/or with Administrator credentials) so it may work fine in 10 or it may not. jaclaz

No, they are NOT, right now they are ONLY a bunch of senseless, unreferenced strings, that most probably you can (although I seriously doubt it) use as some form of mnemonics to make a number of modifications to system files. Try doing this mental experiment, imagine that your computer and all your data including files and notes are not available, let's say you are on a trip abroad and you cannot reach your computer nor anything in India, the only thing you have is a pristine (perfectly working) unpatched XP install on a computer and access to Github and to the public internet. Do you believe that in the above condition you can re-create EXACTLY the patches and apply them? If Yes, then your *whatever* is sufficiently self-contained and replicable, at least by you, good. , now try pointing a friend of yours, an average experience low-level programmer to that Github page, give him a reasonable amount of time, let's say 5 to 10 hours, to recreate from the contents of Github the SAME, EXACT results contained in the installer. Do you believe he will manage to do it? If Yes, then your *whatever* can be considered some sort of replicable source code, otherwise it remains a bunch of senseless, unreferenced strings. jaclaz

The drivers for XP and the drivers for 9x/Me are very different, it is entirely possible that for *whatever reasons* the XP version of a same release is crappy and the 9x/Me version of the same works fine, the Nvidia drivers are AFAICR a huge PITA, but they should have at least basic ffunctionalities (even in versions that are otherwise crappy). The 77.72 havng issues with XP SP2 is strange (in the sense that the driver is 2005 whilst SP2 is 2004). In any case do try the 77.72 driver in Windows 98 as ragnarol suggested, and see what happens. jaclaz

Well, tripredacus asked you the actual blue screen message and error code, perfecthog05 asked you which OS's were involved, Dibya answered that it is a dual booting XP-XP situation, posting a code (most probably wrong), I asked him (who stated being a friend of yours) to double check the error code and I got back "it seems kinda ahci driver issue", then you posted a piece of info that Dibya already posted. It doesn't seem like a conversation between people that can understand each other, being deaf was just a possible explanation, of course an absurd one since this exchange happened in writing. jaclaz

It is such a rare occasion to have these conversations between[1] deaf people .... jaclaz [1] should be "among"

Interesting,"Non-compilable source code", your personal dictionary has "queer" entries, I just however added it to mine with definition: "a bunch of mostly senseless random strings, sometimes used to show to some what one is doing while pretending it being a computer project source code" jaclaz

I can see that the file contains snippets of C and some assembly, thanks , HOW one is supposed to make any use of them was the question, you seem like suggesting now that some one should frobble the mifty through a gnooting, fardetical mawer, most probably the adverb "exactly" belongs to an alien (to you) dictionary. I was asking what was the procedure for getting from point A (the alleged "source" code) to point B (the final, working, program/whatever, byte, by byte identical to the binary version that is nowhere to be found on that Github page and that possibly is still represented by the contents of the queerly named and password protected installer Heinoganda made earlier referenced). The generic idea of source code is that there is a procedure, with a given set of tools, capable of reproducing the compiled code, IMHO the procedure should be documented (even minimally) and as well the set of tools needed should be listed, otherwise the project is irreproducible and thus worth nothing. To me (but I am not a programmer) the kernel32.txt on that github seems like a crappy mishmash of unreferenced, uncommented, semi-random strings (some of which representing known DLL functions) interspersed with snippets of assembly mnemonics and C functions, but most probably it is just me that cannot grab the meaning of that stuff. jaclaz