jaclaz

Actually judging from what has been posted, the issue is that the hard disk is not seen at all (not even with a small partition like 2 or 4 Gb). @basilico Is it by any chance a SATA disk? If this is the case you either: supply the SATA drivers on a "F6 floppy" (or similar) integrate the SATA drivers set the BIOS to "IDE compatibility mode" (or similar setting) Otherwise (AFAICR), there is no problem normally in starting the Windows setup, create a senceful sized partition for the OS, install it normally, and, after install, update the running system to SP4, eable BIG LBA and do the rest of the partitioning. jaclaz

More OT news : Tokyo Court Rules For Samsung, Says It Didn't Violate Apple Patent http://e.nikkei.com/e/fr/tnks/Nni20120831D3ZJF815.htm Anyone catching here: http://www.bbc.com/news/technology-19425051 the irony that ultimately the ones that first said that Samsung was copying Apple were the good Google guys (and that this is one of the key point of the jurors decision)? jaclaz

NO reason whatsoever to be happy , as the XP virus is an evolution (bloated) of the 2K one . jaclaz

That's how I did it initially (Win98 partition within BIOS size, extra FAT partitions all within <137GB, NTFS in the end), but what rleow brought up makes sense. Some FAT partitions are outside the the BIOS detected 8GB size. Some things may try to write there before Windows loads its native drivers, particularly if there's software installed there. That might lead to corruption. My vague understanding is that this isn't a problem with XP which loads its native drivers early.It would be interesting to check what happens when writing above BIOS size but below 137GB, but that's for another time, and the findings may not be generic. Well, then call me "dense" but I confirm not understanding. As I see it there are three main "zones" (rounded/simplified) 0<=x<8 Gb 8<=x<137 Gb 137 Gb <x If the issue is with "pure CHS", *anything* using CHS (and not LBA) to access zones #2 and #3 is a potential issue. If the issue is with lba-28/48 bit, *anything* using LBA 28 to access zone #3 is a potential issue. There could be THREE additional issues, i.e. partitions/volumes not entirely inside a given zone, i.e. : partition starting inside zone #1 BUT ending in zone #2 partition starting inside zone #1 BUT ending in zone #3 partition starting inside zone #2 BUT ending in zone #3 but let us exclude this since you are smart enough to NOT create this kind of "cross-border" partitions . Now if you "limit" the disk to only zone #1 size everything is fine, but (and still if I get it right what you are doing have done) if you "limit" it to only zones #1 and #2, the only additional safeguard (when compared to making only visible to DOS/Win9x partition types) is that you cannot, by mistake, create a partition crossing the border between zones #2 and #3. Am I missing something? More explicitly, what is the expected difference (possible issues) between (simplified): a 160 Gb hard disk with a CHS compatible 8 Gb partition and another one 137-8=129 Gb in size and rest of the space unpartitioned/unallocated a 160 Gb hard disk with a CHS compatible 8 Gb partition and another one 137-8=129 Gb in size and rest of the hard disk made unaccessible through HPA or similar a 160 Gb hard disk with a CHS compatible 8 Gb partition and another one 137-8=129 Gb in size and rest of the hard disk with a NTFS partiion 160-137=23 Gb in size The way I understand it, what rloew wrote is: to be on the "safe" side, you NEED to use a DDO to have no issue with zone #2 my DDO not only will fix issue in zone #2 but will also allow to use zone #3 Which I still read as: without a DDO you should limit the disk to 8 GB (zone #1 ONLY) whatever way you like, i.e. both through leaving further space unallocated or using it for partitions not recognized by DOS or using a HPA method or hardware "clamp" if available. with a "normal" DDO you should limit the disk to 137 GB (zone #1 and #2) whatever way you like, i.e. both through leaving further space unallocated or using it for partitions not recognized by DOS or using a HPA method or hardware "clamp" if available. with a "special" DDO you could avoid any limit and have all three zones available jaclaz

Try having a look at the "my500GB.img" with dmde: http://softdm.com/ even if it is a tool that is not ( like TESTDISK) suitable to be used with a less then advanced knowledge of the NTFS filesystem, you should be able to understand if there is an issue with the $MFT or with the actual filesystem contents. Another thing that you could do is to extrract some sectors starting from 6,291,519 and use on them this tool: http://www.forensicfocus.com/Forums/viewtopic/t=8010/ http://code.google.com/p/mft2csv/ just to understand if the $MFT contains valid data or if it is "the issue". If this latter is the case, PHOTOREC may still be able to find many files.... jaclaz

What I am clearly missing is, since you have NO issues with BIOS (i.e. the thingy, if I got it rightly, boots normally) what is the issue with simply leaving the "rest of the disk" UNpartitioned? (or possibly using a partition ID that Win 9x surely cannot use/access (like the 0x07 NTFS or one of the 0x8x Linux ones)? jaclaz

No. At least up to version 10.*something* Opera is "kosher". And as said in Firefox it can be turned off by the user. @Joseph_sw That would be really mean , byut yes, I dont see why it wouldn't be possible.... jaclaz

Yes, besides your "negative" effect , once you find what is happening you may have actually found a hidden treasure for projects like WinFE: http://reboot.pro/forum/109/ which right now is "blocking" the mount manager, while it seems to me like by accident you managed to block at a "lower" level than that, see also this: http://reboot.pro/15883/#entry142971 there is a reference to "volmgrx" (or you could try building a WinFE ansd see if it behaves like your current build jaclaz

They just mention various limitations, but I don't think there's a WD tool to set it, but... ...but: http://wdc.custhelp.com/app/answers/detail/a_id/936/~/operating-system-and-bios-limitations---137-gb,-32-gb,-8.4-gb jaclaz

jaclaz

There is a similar thingy for WD drives: http://wdc.custhelp.com/app/answers/detail/a_id/936/~/operating-system-and-bios-limitations---137-gb,-32-gb,-8.4-gb jaclaz

There must be *some* service (or "driver" or "upper/lower filter" ) that wasn't started or wasn't started successfully. Can you try using a tool like (I have no idea if it could run in your environments) like serviwin: http://www.nirsoft.net/utils/serviwin.html save the lists and compare them? Particularly what about Partmgr.sys? http://www.davewolf.net/2010/02/fixing-partmgr-sys-partmgr-failing-to-start jaclaz

Well, said from an Italian , your English is much better than the "average" we find on this forum, I wouldn't be so critical about it . The sheer "electrical/electronic" handling is not particularly complex, once you will hvae reviewed the guide you will see how it is little more than (say) find out why your Chrstmas tree lights don't work.... The real issue here is that unlike for the 7200.11 (and to a far lesser degree the 7200.11 ES2) for the LP we have little "certainties", and scarce informations on both the "cause" and the "remedy". But don't worry, shouild you have no other choices and decide to "go ahead", someone will assist you. jaclaz

See if this helps : In case of need jaclaz

So, it is a "normal" USB stick? How comes you had three entries for it in the device manager? Still, you should have seen an anomaly when going through the Registry keys (provided that the still missing answer to WHAT?/HOW? is that is the "that" ) The error 43 can only happen (AFAIK) when repeatedly inserting a device (which is seemingly not your case) or when there is a conflict between two drivers, it's really strange what you report, I don't recall having ever seen more than one entry in device manager for the same device (either working or with ! or ? ) .... jaclaz

No problem, the idea was for a "perfect world" , which this isn't, evidently . Not really (if one wants not - for any reason - the NUSB ), but it's still fair enough , it's your project and you manage it the way you think fit, that's exactly why I stated how it is not matter for "voting". A (IMHO) fair request/proposal was submitted, and a (stil IMHO) fair reply (alas negative) has been given, I would say it's time to move on..... jaclaz

Through WHAT? HOW? What do you mean by "I disconnected my RDP key"? WHAT (the heck) is a RDP key? Those should still be connected to : http://code.google.com/p/buncha-toolz/wiki/AUTORUN_DISABLE_Documentation jaclaz

Yes, this latter is the "expected" result. The "vcredist_x64.exe" file has actually a (single - meaning that it is NOT fragmented) extent on disk, (though the 1220 sectors do not sound "right" ), whilst the netcfg-86477109.txt has NONE (because it is self-contained in the $MFT entry). It was only to show you how and why the "4.00 KB (4,096 bytes) is a "lie" (or if you prefer "a glitch in the matrix"). If you have (say) 10,000,000 of such files, the capacity of the disk won't be reduced by 10,000,000*4,096 bytes = ~38 Gb but the $MFT will have some 10,000,000 more entries and probably will be larger by around 10,000,000*1,024 bytes, i.e. your available space will be reduced by about 1/4th of the above, but the $MFT will be HUGE. jaclaz

For NO apparent reason , and clearly OT besides the humour , it is worth to notice the actual date the thingy was published: jaclaz

It's strange. I mean, if you had an evident benefit from clearing the database and now you are back to the same situation (possiby worse as you were talking of 30 seconds ÷3 minutes and now you have 5÷10 minutes ) there must be *somehting else* going on, but then again originally cleaning the device database could not have created a speeding up. Try checking manually the relevant keys listed here: jaclaz

Have you used this program before? It doesn't seem to work for me... C:\Drivers>GetFileExtents c:\windows\system32\netcfg-86477109.txt initFileTranslation: The handle is invalid. Maybe it doesn't work on Windows 8? Try it with some other (bigger in size) file, first . jaclaz

AND don't forget to tell MS how you tried to provide a WIndows 8 but you failed and had to resort to a Windows 7 because the customer thought that the Windows 8 Metro Nameless Crap Interface sucks big.... jaclaz

Yep , if you "proceed" along the lines of this: http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step you should get for each disk the appropriate partition sizes/offsets/etc. The dd.exe --list output confirms that *somehow* the actual disks are seen but are seen as UNpartitioned media (a single partition on each), and that they are not "linked" to any "volume". They are "strange" results. Can you try running MountStorePE and Showdrive? http://reboot.pro/10169/ (though I think they operate at a somewhat "higher" level than the one you are having the issue at) jaclaz

Good, BUT, still, the 4096 bytes is most probably a lie..... Try getting the file extents for those files.... http://www.wd-3.com/archive/luserland.htm jaclaz

JFYI (and for a seemingly needed quick laugh ): page__view__findpost__p__951837 I think there are NO limits to "worse" , but quite frankly, I would be puzzled by a product that not only detects an "own" app as a virus, but additionally affirms that it has deleted it while it hasn't..... jaclaz