d2007 & runtime error 255

I have an app that runs on a flash drive and one of the functions is to
make a clone of itself to a new flash drive. All that works fine. At
the end I tell the user to put back the original flash drive or
continue working on the new one. When the dialog completes, if they
leave the copied flash drive in place the program seems to work but
doesn't. A separate empty window opens with the programs name but no
content and it does nothing.

I decided to restart the program at the end. My first approach was to
to a postquitmessage followed by a shellexecute. That actually worked
but after the program restarted, the cursor remains an hourglass for a
bit and then a "This program performed blah..blah..blah" message popped
up and when you close it I get a dialog box with Runtime error 255 at
0042021C. When I looked at the technical details it said "inpage error
at ...". Nothing on Google for error code 255 seems relevant. I googled
"restart Program" and found nearly the exact same thing I was doing
except it was shellexecute first and then appliation terminate.

I changed to that and it still fails exactly the same way -- every
time. I tried this on vista and I get no such error messages. Note when
I accept shutting down the program, the new instance works just fine so
the error must be coming from the old instance.

I'm just about ready to make a batch file to restart the program.
Anyone have a better idea or know what the 255 error relates to? Mostly
I'm working in xp-pro on a ms vm on a vista business machine so I can't
actually test the program there. I use a separate machine with xp-pro
to test but the error also happens on XP-Home.

--

Joe H wrote:

> I have an app that runs on a flash drive and one of the functions is
> to make a clone of itself to a new flash drive. All that works fine.
> At the end I tell the user to put back the original flash drive or
> continue working on the new one. When the dialog completes, if they
> leave the copied flash drive in place the program seems to work but
> doesn't. A separate empty window opens with the programs name but no
> content and it does nothing.
>
> I decided to restart the program at the end. My first approach was to
> to a postquitmessage followed by a shellexecute. That actually worked
> but after the program restarted, the cursor remains an hourglass for a
> bit and then a "This program performed blah..blah..blah" message
> popped up and when you close it I get a dialog box with Runtime error
> 255 at 0042021C. When I looked at the technical details it said
> "inpage error at ...". Nothing on Google for error code 255 seems
> relevant. I googled "restart Program" and found nearly the exact same
> thing I was doing except it was shellexecute first and then
> appliation terminate.
>
> I changed to that and it still fails exactly the same way -- every
> time. I tried this on vista and I get no such error messages. Note
> when I accept shutting down the program, the new instance works just
> fine so the error must be coming from the old instance.
>
> I'm just about ready to make a batch file to restart the program.
> Anyone have a better idea or know what the 255 error relates to?
> Mostly I'm working in xp-pro on a ms vm on a vista business machine
> so I can't actually test the program there. I use a separate machine
> with xp-pro to test but the error also happens on XP-Home.

What you are doing is equivalent to sawing off the branch you are
sitting on, the results are usually painful <g>. Keep in mind that
Windows runs executables by mapping the executable file into memory,
basically using the memory mapped file API. The virtual memory manager
will then make sure accessed memory pages are copied from the file into
RAM as needed. But if some page is not accessed for some time it may
also be removed from RAM again, to be reloaded the next time it gets
accessed. So, while the program is running, there is a fixed link
between the file on disk and the program in memory. And now you come
and remove the drive the program file sits on. This will continue to
work as long as page access can be satisfied from memory or the file
system cache. But when a new flash drive is connected to the same port
(which means it gets the same driveletter) the cache will be flushed.
And then the next access of the virtual memory manager to the disk file
will barf.

What you are trying to do is not viable, IMO. The program can copy
itself from the flash to a temp location on the harddisk, start a small
helper program from that image and terminate. The helper can then
prompt the user to insert a new drive, copy the temp image to the flash
drive, start a second helper from the flash drive and terminate. The
second helper can then delete the temp image.

--
Peter Below (TeamB)
Don't be a vampire (http://slash7.com/pages/vampires),
use the newsgroup archives :
http://www.tamaracka.com/search.htm
http://groups.google.com

Peter Below (TeamB) wrote:

> Joe H wrote:
>
> > I have an app that runs on a flash drive and one of the functions is
> > to make a clone of itself to a new flash drive. All that works fine.
> > At the end I tell the user to put back the original flash drive or
> > continue working on the new one. When the dialog completes, if they
> > leave the copied flash drive in place the program seems to work but
> > doesn't. A separate empty window opens with the programs name but no
> > content and it does nothing.
> >
> > I decided to restart the program at the end. My first approach was
> > to to a postquitmessage followed by a shellexecute. That actually
> > worked but after the program restarted, the cursor remains an
> > hourglass for a bit and then a "This program performed
> > blah..blah..blah" message popped up and when you close it I get a
> > dialog box with Runtime error 255 at 0042021C. When I looked at the
> > technical details it said "inpage error at ...". Nothing on Google
> > for error code 255 seems relevant. I googled "restart Program" and
> > found nearly the exact same thing I was doing except it was
> > shellexecute first and then appliation terminate.
> >
> > I changed to that and it still fails exactly the same way -- every
> > time. I tried this on vista and I get no such error messages. Note
> > when I accept shutting down the program, the new instance works just
> > fine so the error must be coming from the old instance.
> >
> > I'm just about ready to make a batch file to restart the program.
> > Anyone have a better idea or know what the 255 error relates to?
> > Mostly I'm working in xp-pro on a ms vm on a vista business machine
> > so I can't actually test the program there. I use a separate machine
> > with xp-pro to test but the error also happens on XP-Home.
>
> What you are doing is equivalent to sawing off the branch you are
> sitting on, the results are usually painful <g>. Keep in mind that
> Windows runs executables by mapping the executable file into memory,
> basically using the memory mapped file API. The virtual memory manager
> will then make sure accessed memory pages are copied from the file
> into RAM as needed. But if some page is not accessed for some time it
> may also be removed from RAM again, to be reloaded the next time it
> gets accessed. So, while the program is running, there is a fixed link
> between the file on disk and the program in memory. And now you come
> and remove the drive the program file sits on. This will continue to
> work as long as page access can be satisfied from memory or the file
> system cache. But when a new flash drive is connected to the same port
> (which means it gets the same driveletter) the cache will be flushed.
> And then the next access of the virtual memory manager to the disk
> file will barf.
>
> What you are trying to do is not viable, IMO. The program can copy
> itself from the flash to a temp location on the harddisk, start a
> small helper program from that image and terminate. The helper can
> then prompt the user to insert a new drive, copy the temp image to
> the flash drive, start a second helper from the flash drive and
> terminate. The second helper can then delete the temp image.

Thanks. Copying the program to the new flash works perfectly. So the
only real problem is restarting the program. My first thought about
this is consistent with your description of sawing off the limb that
you are on. That said, I see many recommendations on Google to do
exactly that to accomplish the goal--and I'm really curious as to why
the error doesn't show on Vista.

After I submitted this post, I investigated using a mutex in the
program to give the existing instance a chance to terminate before
starting the new one. This is similar to using a mutex to make sure you
only have one copy of the program running at a time. I haven't tried
this yet but it seems like it would work. The only question is whether
it will eliminate this error message.

Before applicaton.initialize,
attempt to open a mutex with a known value
if the returned value is not zero, it means the program is running
already. In that case do a waitforsingleObject with a timeout of say 5
seconds. If the single object does not become available then, close
down the new instance with a message.
When the result is zero, create it.

I probably won't be able to try this until later today or tomorrow but
I'll post the results if no-one says different.

Peter,

> What you are doing is equivalent to sawing off the branch you are
> sitting on, the results are usually painful <g>. Keep in mind that
> Windows runs executables by mapping the executable file into memory,
> basically using the memory mapped file API. The virtual memory manager
> will then make sure accessed memory pages are copied from the file into
> RAM as needed. But if some page is not accessed for some time it may
> also be removed from RAM again, to be reloaded the next time it gets
> accessed. So, while the program is running, there is a fixed link
> between the file on disk and the program in memory. And now you come
> and remove the drive the program file sits on. This will continue to
> work as long as page access can be satisfied from memory or the file
> system cache. But when a new flash drive is connected to the same port
> (which means it gets the same driveletter) the cache will be flushed.
> And then the next access of the virtual memory manager to the disk file
> will barf.
>
> What you are trying to do is not viable, IMO.

There's a small twist to the saga. When removable media (or a network
drive) is involved, Windows is documented to copy the entire EXE into
memory and use the page file for backing store. In other words, if the
USB drive appears as removable media to the operating system, what Joe
is trying to do should work.

But, there's yet another twist to the saga. USB drives can appear as
removable media or as a harddrive; a decision made by the drive
manufacturer.

- Brian

Peter Below (TeamB) wrote:

>
> What you are doing is equivalent to sawing off the branch you are
> sitting on, the results are usually painful <g>. Keep in mind that
> Windows runs executables by mapping the executable file into memory,
> basically using the memory mapped file API. The virtual memory manager
> will then make sure accessed memory pages are copied from the file
> into RAM as needed. But if some page is not accessed for some time it
> may also be removed from RAM again, to be reloaded the next time it
> gets accessed. So, while the program is running, there is a fixed link
> between the file on disk and the program in memory. And now you come
> and remove the drive the program file sits on. This will continue to
> work as long as page access can be satisfied from memory or the file
> system cache. But when a new flash drive is connected to the same port
> (which means it gets the same driveletter) the cache will be flushed.
> And then the next access of the virtual memory manager to the disk
> file will barf.
>
> What you are trying to do is not viable, IMO. The program can copy
> itself from the flash to a temp location on the harddisk, start a
> small helper program from that image and terminate. The helper can
> then prompt the user to insert a new drive, copy the temp image to
> the flash drive, start a second helper from the flash drive and
> terminate. The second helper can then delete the temp image.

If you start the program on the flash, then remove it and try to close
it without the flash drive in place, the window changes to an empty
form and gives an error when it's closed. So I'm guessing your're
right. I tried the mutex and that really didn't change anything.

I just tried running the program from the flash, removing it, then
replacing it and closing the program and the same thing happens as if I
had not put the flash back.

Is there a way to trap this error and just ignore it? That would be by
far the simplest solution and would be useful whenever running from the
flash if the user pulls the flash out while the program is open.

I was really hoping to not have to ship another program. Could this be
done by allowing the exe to run twice and useing parameters when
calling so that the main program would copy the files to temp. Then
start same program from temp and shut itself down. The second copy
would see the parameter and instruct the user to insert the new flash
drive and would copy itself, then run the other program again with a
parameter that deletes the temp folder. Again shutting itself down.

Actually couldn't this be done before application.initialize and in
these copy modes, the app would just halt before initializing. The exe
file would already be present in the temp folder and on the new flash
drive and therefore would need only the right parameters to perform the
extra functions.



--

Joe H wrote:

> If you start the program on the flash, then remove it and try to close
> it without the flash drive in place, the window changes to an empty
> form and gives an error when it's closed. So I'm guessing your're
> right. I tried the mutex and that really didn't change anything.

In fact Windows should warn the user that the drive is in use if you
try to remove it using the "remove hardware safely" popup from the try
icon (XP, don't know how Vista handles that). Of course the OS cannot
prevent you from just ripping the flash drive from its USB socket.

> Is there a way to trap this error and just ignore it?

I don't think so. It's too low-level, you are sabotaging the VMMs
working by unplugging the drive.

> I was really hoping to not have to ship another program. Could this be
> done by allowing the exe to run twice and useing parameters when
> calling so that the main program would copy the files to temp. Then
> start same program from temp and shut itself down. The second copy
> would see the parameter and instruct the user to insert the new flash
> drive and would copy itself, then run the other program again with a
> parameter that deletes the temp folder. Again shutting itself down.

That should work OK if your program is not written to not allow a
second instance of it to be started.

>
> Actually couldn't this be done before application.initialize and in
> these copy modes, the app would just halt before initializing.

You an try to do it from a procedure you call from the DPR file before
Application.Initialize. An Exit after the call would directly terminate
the application. Of course the code you use must then not make any
reference to forms etc. that are autocreated in the DPR file.


--
Peter Below (TeamB)
Don't be a vampire (http://slash7.com/pages/vampires),
use the newsgroup archives :
http://www.tamaracka.com/search.htm
http://groups.google.com

Peter Below (TeamB) wrote:

> > Actually couldn't this be done before application.initialize and in
> > these copy modes, the app would just halt before initializing.
>
> You an try to do it from a procedure you call from the DPR file before
> Application.Initialize. An Exit after the call would directly
> terminate the application. Of course the code you use must then not
> make any reference to forms etc. that are autocreated in the DPR file.

I'll try this way. It should make virtually no difference in the exe
file size since I'm just moving code around. Making a helper app is
going to take 100k+ as a upx'd minimum, but more of a pain is handling
the helper exe's with versioning and upgrades etc. Thanks for the
feedback.

--

Peter Below (TeamB) wrote:

> Joe H wrote:
>
> >
> > Actually couldn't this be done before application.initialize and in
> > these copy modes, the app would just halt before initializing.
>
> You an try to do it from a procedure you call from the DPR file before
> Application.Initialize. An Exit after the call would directly
> terminate the application. Of course the code you use must then not
> make any reference to forms etc. that are autocreated in the DPR file.

That works great and it did not increase code size at all. In my main
form's formcreate event, I check for the existence of the temp folder
and if it's there it deletes it. That eliminates one of the steps.

I'm not super pleased with the form image being gone throughout the
process but it would probably be more disconcerting to have it appear
and dissapear. Would be nice to maybe copy it to a bmp, then gray that
out and paint that on the desktop while all this is working. But I
don't think I'll mess with that just now.

Only one problem and that is with the windows shfileoperation. The
copying dialog box shows up offset below and to the right of screen
center instead of being centered on the screen. That's a bit anoying.
Any way to make that center? I can live with it but if there is an
easy way to fix that I'll do it.

Again, thanks for the feedback.

When I was checking to make sure all worked including deleting the
folder in the temp folder, I found about 300 megs of crap! What's the
deal with apps like adobe, winzip and others trashing that folder --
and I can't even delete some of the files though afik I have nothing
running except services and such. There are dozens of installers, dlls,
help files and a ton of xml files, trg files (whatever those are) etc.
I managed to delete about 4000 files and empty folders, but what the
hell! Is this just lazy programming?

--