will not boot - stumped

[BC_Programmer]

no message resulted from above so i concluded it was not loading the boot sector. at this point i was
stumped. did not see any point in trying to fix the boot sector, since the data itself was ok. i then tried
this forum for help.

I found this documentation alongside WriteFile/WriteFileEx, in the MSDN:

If you write directly to a volume that has a mounted file system, you must first obtain exclusive access to the volume. Otherwise, you risk causing data corruption or system instability, because your application's writes may conflict with other changes coming from the file system and leave the contents of the volume in an inconsistent state.

With that in mind, use 0 (exclusive access) for the dwShareMode argument to CreateFile.

Another consideration for exclusive access might be to explicitly lock the volume using DeviceIoControl() and FSCTL_LOCK_VOLUME.

(the MSDN states that Windows XP is the minimum supported client, but that isn't true, it's supported back to NT 3.5)

using createfile and treating it like just another file, a lot of that sector location junk gets handled by the OS.

No, it doesn't. Directly accessing a volume means you don't want the OS to do things for you. Writes/reads have to be aligned on sector boundaries and the buffer written or read to/from needs to be a multiple of the sector size.

it really doesn't matter what real sector i am in

Well.. if you want to write to the boot sector, I would imagine that is rather important.(although I take it you mean 'real' sectors as opposed to those translated by the disk, which would of course not really matter, as you note) Also, direct physical access goes past the actual Filesystem driver, which may also be relevant.

after all, the whole point of an OS is to make it easier to work with the thing, not to send our money to microsoft. let windows do all the dirty work. i'll worry about cases where windows can't deal with it, when it happens.

The way you are opening the volume bypasses both the file system driver as well as any interfacing between windows and that file system driver; you are dealing directly with the functionality that the file system driver would use.

i'm not so much brave, as old. i used to write low level format assembly programs for my trash-80. and
in those days low level was LOW LEVEL. if i could overcome my AADD long enough to learn write a kernal
mode program, i'd be working with the drive controler for this stuff, instead of having windows do the work. .

This is something of a problem. You are trying to deal with a co-operative, pre-emptive, protected mode Operating System the same way you did with a real-mode Operating System. The latter exposed everything to you, and you could change anything. The former does not, by virtue of being a multi-tasking environment, and applications need to share resources. Additionally, there are 'checks and balances' to prevent copius changes to the system, thus the hoops for exclusive access and sector alignment (because you are bypassing much of the functionality of the OS).

Another important consideration: NTFS keeps a backup of the boot sector. I'm not sure how it is employed, but it might be used in some manner and that somehow prevents the boot. That is assuming you are using NTFS.

Also, the symptoms you describe are usually caused by a corrupt MBR. Since the first instance was almost certainly caused by your application, I don't see any reason to think that the second write (to add the JMP to output the message) was more successful.

Consider comparing what your application sees with what DSKPROBE sees. DSKPROBE is a tool that can be found on the Windows 2000 CD-ROM.

[Geek-9pm]

Thanks, BC.
Wish I could have said that. Yes, the Windows OS is now very mean and limits some tings you do.
For reference, this gives some tips on using the MBR.
http://thestarman.pcministry.com/asm/mbr/BootToolsRefs.htm
One issue not well  documented is about the sectors that come after MBR and before the first partition. Some systems use that area for some kind of extension to the MBR boot process. Some references deny that. Or ignore it.

[alexlauf]

reply for BC_Programmer :

With that in mind, use 0 (exclusive access)...

I probably should have done this, but my first inclination was to try to
co-exist with any other things wanting access.

explicitly lock the volume using DeviceIoControl()

i did not think of this. although when i have the boot sector open,
how much real traffic should there be to that sector ? it is no
real surprise that it only showed up when i rebooted. the same can
not be said about other sectors though, so i guess i should do the
locking bit. also this was originally to be mainly for the dvd rom,
so locking was not really an issue, since i did not plan any writing.

lets not drag the dvd into this, by the way ; it has its own quirks,
some i am still figuring out, and if we start on that, this will become
the thread that never dies.

Writes/reads have to be aligned on sector boundaries ...

buffer a multiple of the sector size.

i did these, at least as far as i could tell. i used DeviceIoControl
rather than GetDiskFreeSpace to get the disk and sector size. i wonder
if they might be disagreeing with each other ?

checking the literature, my buffer address probably is not alligned in
memory to a sector boundry. seems like if this was part of the problem,
it would either give back bad data, or not work, like it does when not
sector alligned. although i might try and fix this later and see if it
crashes again, now that i know what to do about it when it won't boot.   

"it really doesn't matter what real sector i am in"

if you want to write to the boot sector, I would imagine that is rather important.

what i meant was, for instance if i go to the start of the disk, and it shows me
the boot sector consistantly, i don't care if some drive logic is really showing
me some sector in the middle where it remapped the sector to because the real
start sector had an error. if the OS thinks it is at sector 0, and presents me
with the boot sector, thats good enough for me. if the thing was not handling all
the junk like sectors starting at 1, chs or lba, and similar, it would not be
working at all. and microsoft would be telling me to use something diffrent.

Also, direct physical access goes past the actual Filesystem driver, which may
also be relevant

some stuff may be bypassed with this method, but there must still be a good hunk
of the filesystem between me and the drive. part of the design philosophy was
to be able to treat EVERYTHING like a file, at least with this part if the API.
personally i'd rather have drive specific API calls.

You are trying to deal with a co-operative, pre-emptive, protected mode Operating System

I know, that is one reason i did not go with exclusive access.

NTFS keeps a backup of the boot sector.

I know, although i have yet to locate it. it's position varies depending on the
specific OS. I don't think this is a factor here ; it seems to have failed
during the bios sector loading. if bios was aware of an alternate boot sector
copy, it should have used it, and I'd never have known my main sector was bad.
I suspect that bios us unaware of the copy and it is there for use by the OS,
probably for fixboot, and similar. and it possibly might have come into play
if it had booted, and the OS saw the odball boot sector ; but it never made
it that far. 

Also, the symptoms you describe are usually caused by a corrupt MBR.

i agree, but as i said, i kept looking at it and it kept looking ok. both the
before and after reads of the data looked identical.

Since the first instance ... caused by your application, I don't see any reason
to think that the second write ... was more successful.

It was just as successful - both failed. and that is what told me boot up was
failing before running the boot sector code. as to why, since the OS ( when
running ) and my app see the data just like it should be, i did not suspect
my stupid app was the cause. why the data can read and look ok with the OS,
but not by the bios loader, is still unanswered. and you would think the bios
would display a message or beep or something when it hit a problem.

Consider comparing what your application sees with what DSKPROBE

i would love to. part of the problem is DSKPROBE won't show me any physical
drives to select. I don't know if it is a quirk in DSKPROBE, or more likely,
of my system. for that matter, if DSKPROBE had worked, i would not be writing
this thing in the first place.

or maybe i might still have done it just to do it. i won't be really happy,
until i can do ANYTHING with this system, although typically, everyone else
will probably be running windows 47 ( or Win 2047, depending on the marketing
guys ) on organic computers by that time. 

---------------------------------------------------------------------

reply for Geek-9pm :

http://thestarman.pcministry.com/asm/mbr/BootToolsRefs.htm

neat link. I'm going to try some of the stuff from it. a lot of it looks like
the sort of things i like to play with.

 

[BC_Programmer]

some stuff may be bypassed with this method, but there must still be a good hunk
of the filesystem between me and the drive.

Nope. NTFS.SYS, FASTFAT.SYS, etc, are completely out of the loop. In fact they use the same functions (well, the native version of those functions at least) to perform their own operations.

part of the problem is DSKPROBE won't show me any physical
drives to select.

weird. You could try another alternative program, Although I've not used it for a while (I've not needed a direct disk editor beyond the curious for a while) you could try Hxd. It really is quite feature-filled.

Basically, what I meant is that since the program can't seem to write it properly (the sector is obviously changed, since it won't boot) than there isn't much reason to have faith that it is reading properly, either. (thus the idea to use another software tool).

As to the issue regarding locking, it's not so much that there could be a contention issue with other applications writing to that location as well, but sharing issues could easily cause these sorts of issues, particularly with something as sensitive as direct disk editing. Best to make sure the entire operation is atomic and completed before allowing anything else access to the drive.

[alexlauf]

sorry about the delay, life keeps interfering with my computer time.

Nope. NTFS.SYS, FASTFAT.SYS, etc, are completely out of the loop.

let me try to clarify what i meant. i misspoke a bit when i refered to the code as
"filesystem". the idea is to be able to treat  EVERYTHING like a file. by that i meant
the basic file functionality is there, and some basic ops ( open close, read, write,
sometimes seek ) can be used. that is why one call "createfile", is being used for
so many things in the first place. you are probably correct about NTFS, FASTFAT being
out of the loop with physical drives, but they are also not needed in this context.
there is no need for keeping track of free / used clusters, handling streams,
etc that filesystems normally handle. you should be able to open, read, write,
etc, without needing to care what it is you are working with. for example, you could
open a tape drive for output, open a hard drive for input, and dump the whole thing
to tape ( tape ? what's that ? ) with the same program, changing only the actual
device names. they do this all the time in unix / linux. i am actually surprised that we
still have to worry about something as hardware specific as sector boundries & sizes. i
havn't tried it, for example, but i would practically bet that if i read past the end of the
drive i would get an eof error .   

program can't seem to write it properly...
isn't much reason to have faith that it is reading properly

it is obviously doing something wrong ( maybe, see below ), but as i said, i did the
write. later when i did a read, the data was the same. it was writing it correctly somewhere
or somehow, and it seemed  to be able to find it again later ; otherwise, i'd have gotten
garbage back. maybe that somewhere is the wrong place ( due to the buffer alignment problem )
and it crashed depending on exactly where that write ended up.

news :

1. i tried to duplicate the crash, with another drive. of course, i can modify the boot sector
all i want, and it won't crash for me when i want it too ! sometimes i hate these things. if
it really was my app that did it ( still the prime suspect ), there is some other variable
somewhere. since i did not fix my buffer to a sector boundry ( or to anything ) , i wonder
if its moving, being at a good address some days, and a bad address on others ( like the
day when it crashed ).

2. i was all ready with sectorinspector dumps with before and after modification, but i see no
difference, and as said, it didn't crash.

3. i downloaded Hxd. it looks neat. i'll be trying it out next time i try to get that thing to crash.

[Geek-9pm]

Legacy standards are still an issue with Hard Drives that are used in Personal Computers. In tis context, a computer that may conform to the standards set out by IBM. If you want to use any other kind of computer, it is another matter.

The OP needs to wade through this kind of stuff to grasp the problem. It is still with us. Some utilities still go by the partition and cylinder foundry thing.
http://www.cgsecurity.org/wiki/Menu_Geometry
There are more like these. But we could get really buried in a ton of old documentation that still belabors the PC Hard Drive definitions. Modern drive geometry is not longer sector, track, cylinder. It is whatever the manufacture wants it to be for the most effective, fast, reliable way of writing and reading data.
EDIT:
On to put it another way, sector 37 may be right after sector 36 physically.  Or maybe not. It is wherever the firmware assigned it. Tracks not longer have uniform sector count. Maybe that track does have 37 sectors. But the net track might have 35.
One of many references.

However, current disk drives use zone bit recording, where the number of sectors per track depends on the track number. Even though the disk drive will report some CHS values as sectors per track (SPT) and heads per cylinder (HPC), they have little to do with the disk drive's true geometry.
http://en.wikipedia.org/wiki/Logical_block_addressing

[BC_Programmer]

sorry about the delay, life keeps interfering with my computer time.

Same here, actually! Losing one's job tends to complicate life, that's for sure!

that is why one call "createfile", is being used for
so many things in the first place.

There is a fundamental difference here; everything isn't being treated as a file, but rather as a stream of bytes. That may seem like splitting hairs, but I feel it's an important distinction. a File is a component of storage used by a file system. A stream of bytes is just that- a stream of bytes. Windows Sockets, Named Pipes, and so forth are all streams of but not files. Presumably that is really what you mean when you say file, but I've always associated a file as a named entity of storage within a file-system (or papers in a folder ), so I feel that calling it a "file" is a bit ambiguous.

there is no need for keeping track of free / used clusters, handling streams,
etc that filesystems normally handle.

Well of course not! you are "below" that stuff at the level of direct access to the volume. You don't have to deal with them not because the Filesystem is handling it for you but because you don't have to; if you wanted to interpret and read individual files, then you would have to read and interpret that data yourself if you wanted to read the file(s) by using the direct access method.

Legacy standards are still an issue with Hard Drives that are used in Personal Computers.

No they aren't. Unless you have a legacy machine. The legacy "standards" aren't an issue with the hard  drives, they are an issue with the system BIOS in older machines. Cylinder/Heads/Sector addressing has been obsolete for nearly 20 years. Any tool still using those is in fact about that age. LBA is how hard disks are addressed now, but this is even lower than what they are dealing with. Also, as he points out, Sector remapping at the drive level is at the drive level and therefore would be invisible to the OS and thus his application; also, I don't think Sector 0 is remappable even via firmware for a number of reasons, but I'm not sure about that.

[Geek-9pm]

    Legacy standards are still an issue with Hard Drives that are used in Personal Computers.

No they aren't. Unless you have a legacy machine. The legacy "standards" aren't an issue with the hard  drives, they are an issue with the system BIOS in older machines. Cylinder/Heads/Sector addressing has been obsolete for nearly 20 years. Any tool still using those is in fact about that age. LBA is how hard disks are addressed now, but this is even lower than what they are dealing with. Also, as he points out, Sector remapping at the drive level is at the drive level and therefore would be invisible to the OS and thus his application; also, I don't think Sector 0 is remappable even via firmware for a number of reasons, but I'm not sure about that.

Wrong. It was not resolved until 1996. Many are still using PCs and Hard drives made before that year. Fixing  the issue 20 years ago was a pipe dream.
Strop smoking that stuff, BC!

[BC_Programmer]

Wrong. It was not resolved until 1996. Many are still using PCs and Hard drives made before that year.

First, you state "many are still using PCs and hard drives made before that year".... what is your source for this? Where are you gathering this information?

The VAST majority of PCs happen to be running a modern copy of Windows or Linux, so your use of "many" is clearly an attempt at weasel words.

And if you had read my post more thoroughly you might have noticed that bit where I said "Unless you have a legacy machine."

He isn't using a legacy machine, or a legacy hard drive, so this is all a redundant sidebar of redundancy.

[patio]

And if you had read my post more thoroughly you might have noticed that bit where I said "Unless you have a legacy machine."

He isn't using a legacy machine, or a legacy hard drive, so this is all a redundant sidebar of redundancy.

Exactly...