M
mori
Ed Cayce said:
Just check the other threads in the NG, you'll find that Folkert knows
nothing but sniping and trolling
)
Just check the other threads in the NG, you'll find that Folkert knows
nothing but sniping and trolling
)
E
Ed Cayce
Well, Steve N. you are a stud. The dskprobe.exe did the trick - once I
did that I rebooted, chkdsk'ed, popped the drive back in the original
PC and it booted up without a hitch. Of course, it booted up all
infested with spyware & the like... but I know what to do there.
Thanks for your help, also thanks to Joep and Eric, who I think had the
right answer from the beginning, I just didn't know how to do what he
was suggesting.
Happy computing, folks.
did that I rebooted, chkdsk'ed, popped the drive back in the original
PC and it booted up without a hitch. Of course, it booted up all
infested with spyware & the like... but I know what to do there.
Thanks for your help, also thanks to Joep and Eric, who I think had the
right answer from the beginning, I just didn't know how to do what he
was suggesting.
Happy computing, folks.
S
Steve N.
Ed said:
Thanks. Glad it worked. I learned something, too.
Steve N.
F
Folkert Rienstra
Ed Cayce said:
That's the point, I don't know, except that it's a good bet (err, it was a
good bet until you proved me wrong) that the other system changed the
drive letter and that the change to Dynamic had nothing to do with it.
The drive letter is kept on the drive itself but I don't know where offhand.
That is why I don't comment on things I don't know (when others should know
better) but that doesn't mean I can't comment on what I think it *isn't*.
I may not know whether the earth globe is a perfect sphere
or more pumpkin shaped, I do know however that it isn't flat.
I believe Eric's comment was made in a similar sentiment.
S
Steve N.
Folkert said:
You're correct that converting to DD had nothing to do with the drive
letter change. The two are not realated.
It isn't, it's contained within the active OS at the time and how it
enumerates the devices, not the drive itself. For example, you can have
a system with two hard drives and a CDROM drive, under XP lets say they
are assigned letters of hdd0=C, CDROM=D and hdd1=E. Let's also say that
the hard drives are formatted Fat32 so that can be recognized from DOS.
Now boot a DOS floppy disk, including CDROM support. Hdd0 is still C but
now hdd1 becomes D and the CDROM becomes E. Drive letters, with the
exceptions of A, B and C which are reserved in BIOS, are logical
assignments done by the OS.
Yes, you have a perfect right to comment where you see fit, however you
did in fact comment on something you didn't know, the fact that you
thought it *isn't* doesn't negate that, not that that's a big deal.
However, I took deference to how you did it, particulary the comment of
me "posing as an expert", nevertheless I apologize to the groups for my
reactive remarks towards you.
Eric's comment was not inaccurate but was niether detailed nor helpful
to the OP and seemed to presume that the OP would know what he was
referring to.
Steve N.
A
Antoine Leca
In Joep va escriure:
At least he was right on one point: you are the author and more importantly
the beneficiary of the sales of "DiskP**** Part**** *****", but you neglect
to highlight this fact on your preceding post.
One thing is to suggest something;
another thing is to say others' solution are bad and distract the original
poster to _your_ software, without indicating it's advertising.
Antoine
At least he was right on one point: you are the author and more importantly
the beneficiary of the sales of "DiskP**** Part**** *****", but you neglect
to highlight this fact on your preceding post.
One thing is to suggest something;
another thing is to say others' solution are bad and distract the original
poster to _your_ software, without indicating it's advertising.
Antoine
A
Antoine Leca
In Folkert Rienstra va escriure:
Before knowing a solution, it's even better to understand what the problem
really is.
Seems correct.
Well, perhaps it has, finally.
With basic volumes, it is not AFAICT.
With dynamic volumes, it might be stored in the small database (which is at
the end of the 42 partition).
http://support.microsoft.com/kb/234048 says more about it. I cannot certify
how it happens, but it looks like the scheme described there ("importing
foreign dynamix disks") mirrors what Ed described to us.
Antoine
Before knowing a solution, it's even better to understand what the problem
really is.
Seems correct.
Well, perhaps it has, finally.
With basic volumes, it is not AFAICT.
With dynamic volumes, it might be stored in the small database (which is at
the end of the 42 partition).
http://support.microsoft.com/kb/234048 says more about it. I cannot certify
how it happens, but it looks like the scheme described there ("importing
foreign dynamix disks") mirrors what Ed described to us.
Antoine
F
Folkert Rienstra
Antoine Leca said:
As in 'in the end', as in 'after all' ?
That would be new to me. I've never seen it mentioned when the
NT OS flavors ability to remember drive letters came to mention.
I don't think the article you point to supports that either.
It says that it keeps it at the end of the physical drive.
Supposedly you mean the LDM database?
According to the article it is used by Logical Disk Manager that
on it's part advices Mount manager for a drive letter to be used.
But ...
It would certainly explain what happened.
By changing back to Basic that LDM (extra) database would have been taken out of commission.
However:
"1. If the MountMgr database in the system registry has a drive letter re-
corded for this volume, the volume gets the drive letter from the database.
MountMgr makes sure that only one volume owns a drive letter in the database.
2. If the MountMgr database does not have a drive letter for this volume,
MountMgr asks LDM for a "suggested" drive letter for this volume. LDM
looks for a recorded letter in its configuration database and suggests it to
MountMgr. If this drive letter is free, the volume gets that suggested
drive letter and also puts that drive letter into the MountMgr database
to be used during the next mount. "
This suggests that the other system must have changed this drive's
Windows registry settings. That's obviously not the case.
The remaining possibility is that Windows doesn't keep a drive
letter for itself when it is on C:. I find that somewhat unlikely.
J
Joep
Antoine Leca said:
Which was admitted already. He sais my only reason for being here was
selling stuff, which simply ain't so.
I didn't say the solutions was bad. I saif IF ... THEN ...
A
Antoine Leca
We are really drawing plans onto a comet, but that's fine; lurker, don't
build on that until you save your data first, though...
In Folkert Rienstra va escriure:
I'd say, with basic disks, there is no way to "remember" the letter assigned
when the disk travels from a box to another (or even between OS setups on
the same box, as when one is doing multiboot).
There is some form of persistency, but the information is kept inside the
registry, which is private to one OS setup and not exported normally (I
exclude the MIGRATE.INF or ASR.SIF or $DRVLTR$ tricks used while
installing).
Yes, that's my reasonning.
Yes. However, if this decommission happened *after* the recording inside the
registry, its effect will be effectively nullified (case 1. in the KB text
you quoted).
Let's remember in order (and imagine a bit about what is still unclear).
1. volume is alone in case A, named C:
2. computer A fails, drive is moved to case B; obviously there is yet a C:
disk there, so drive gets now D: in case B (in
{caseB}\WINDOWS\system32\SYSTEM). The (inactive)
{caseA}\WINDOWS\system32\SYSTEM, now in D:\WINDOWS\system32\SYSTEM, is left
intact
3. disk is turned to dynamic: Windows adds the LDM database at the end of
the drive, and it records there the fact this drive is named D:.
I assume there is some other change in the MBR which voided the signature
(or perhaps a bit later, when Ed "ran chkdsk which repaired some
problems"...)
4. drive is turned to case A. Windows (MountMgr.sys) boots, does not find
the letter inside the registry because the signatures do not match, finds
the LDM database, finds it matches, finds the letter should be D:, so it
assigns D: as letter for this disk, and... can't boot.
Where I am not clear about is what is then written in the registry
5. dynamic disk is canceled with Eric's (good) trick, so the LDM database is
now decommissioned. Ed said he then successfully booted, so I assume either
the registry was kept safe from the D: "infection" someway, or the signature
was reset again (and then MountMgr.sys will give the "natural" C: letter to
the unassigned volume); Ed could probably disambiguate here, looking at
HKLM\System\MountedDevices, if he sees \DosDevices\D: then it is probably
the second case.
I am not affirmative, it is my best idea of what could have occurred.
Another possibility is that the format to designate a volume inside
HKLM\System\MountedDevices could be different for basic or dynamic disks. In
fact, I guess this is even more possible (but I cannot confirm it right
now). If it is correct, the D: assignation was "forgotten" when the
partition has been reset to 07, creating the same effect as resetting the
signature. Of course, MS does not describe this in its KB, since they do not
support Eric's trick.
Antoine
build on that until you save your data first, though...
In Folkert Rienstra va escriure:
I'd say, with basic disks, there is no way to "remember" the letter assigned
when the disk travels from a box to another (or even between OS setups on
the same box, as when one is doing multiboot).
There is some form of persistency, but the information is kept inside the
registry, which is private to one OS setup and not exported normally (I
exclude the MIGRATE.INF or ASR.SIF or $DRVLTR$ tricks used while
installing).
Yes, that's my reasonning.
Yes. However, if this decommission happened *after* the recording inside the
registry, its effect will be effectively nullified (case 1. in the KB text
you quoted).
Let's remember in order (and imagine a bit about what is still unclear).
1. volume is alone in case A, named C:
2. computer A fails, drive is moved to case B; obviously there is yet a C:
disk there, so drive gets now D: in case B (in
{caseB}\WINDOWS\system32\SYSTEM). The (inactive)
{caseA}\WINDOWS\system32\SYSTEM, now in D:\WINDOWS\system32\SYSTEM, is left
intact
3. disk is turned to dynamic: Windows adds the LDM database at the end of
the drive, and it records there the fact this drive is named D:.
I assume there is some other change in the MBR which voided the signature
(or perhaps a bit later, when Ed "ran chkdsk which repaired some
problems"...)
4. drive is turned to case A. Windows (MountMgr.sys) boots, does not find
the letter inside the registry because the signatures do not match, finds
the LDM database, finds it matches, finds the letter should be D:, so it
assigns D: as letter for this disk, and... can't boot.
Where I am not clear about is what is then written in the registry
5. dynamic disk is canceled with Eric's (good) trick, so the LDM database is
now decommissioned. Ed said he then successfully booted, so I assume either
the registry was kept safe from the D: "infection" someway, or the signature
was reset again (and then MountMgr.sys will give the "natural" C: letter to
the unassigned volume); Ed could probably disambiguate here, looking at
HKLM\System\MountedDevices, if he sees \DosDevices\D: then it is probably
the second case.
I am not affirmative, it is my best idea of what could have occurred.
Another possibility is that the format to designate a volume inside
HKLM\System\MountedDevices could be different for basic or dynamic disks. In
fact, I guess this is even more possible (but I cannot confirm it right
now). If it is correct, the D: assignation was "forgotten" when the
partition has been reset to 07, creating the same effect as resetting the
signature. Of course, MS does not describe this in its KB, since they do not
support Eric's trick.
Antoine
E
Ed Cayce
Wow, nice post-mortem guys. Unfortuantely I don't have that machine
around any more, otherwise I would check out where Antoine asks:
HKLM\System\MountedDevices, if he sees \DosDevices\D: then it is
probably
the second case.
Anyway, I have learned more than I ever expected from this thread.
Thanks!
around any more, otherwise I would check out where Antoine asks:
HKLM\System\MountedDevices, if he sees \DosDevices\D: then it is
probably
the second case.
Anyway, I have learned more than I ever expected from this thread.
Thanks!
F
Folkert Rienstra
Ed Cayce said:
And none of the previously 'perceived' experts involved.
A
Antoine Leca
En Ed Cayce va escriure:
You are welcome to Usenet.
Antoine
You are welcome to Usenet.
Antoine
S
Steve N.
Folkert said:
At least we got him going in the right direction and actually _helped_
him find a solution. All you did was bitch about 'advertising' and
flaunt your self-percieved expertness, insult me without cause, and yet
nothing you contributed to this thread that actually _helped_ the OP in
the least. We did. You're all mouth.
Steve N.
R
Rod Speed
Steve N. said:
All arsehole, actually.
F
Folkert Rienstra
Steve N. said:
By offering a very dangerous way that you didn't even understand what
it did exactly or you would have recommended a partition table editor
instead of a sector editor. It's not even clear whether you understood
that it even was a sector editor that you recommended.
By sheer luck. You even went sofar as to denounce that your solution
wasn't actually the cause of the problem to later be proven wrong yet
again by Antoine, showing how you had no idea of what you were doing.
Actually, you were. And you were all over the place too.
I'll bet that you still don't know what the actual problem was.