EWF RAM

  • Thread starter Thread starter Richard
  • Start date Start date
R

Richard

Here it is again, slightly worded better. I sure hope someone has a pointer
or two. We are in really trying to locate this bug and fix it.

Over last couple of months we have had some systems hang after performing an
upgrade. Let me explain our process/

VIA 667 mhz + XPe SP1 + Headless Device + EWF RAM Reg Component + 256 megs
Ram + 256 Meg Sandisk Industrial

We thought it was DUA so we went a different route by running a batch file
which maps a drive, and does all the work.

A tech plugs into it with laptop and remote desktops to it. He then runs a
small batch file on his Laptop to upgrade a few files.

Complete Listing of the files that get copied - No DLL's or anything else...
1 Single Exe. file 1.20 megs - Application
1 Single Exe. file 425k - Shell
1 Single Text File 294 Bytes - Version Information


Example of the batch file....
Maps a local drive on the laptop to the Target.
PSKill shuts down the application and shell on the Target, so the file can
be copied over the old one.
Performs a Commit,
Performs a shut down restart with a 15 second timer.
Target reboots

There is a 5 second delay between each command in the above batch file. The
batch file works fine.

Each Step of the Batch file has its output redirected to a log file on the
techs laptop, showing each command was sucessful, including the commit.

Now, after the system is restarted, it hangs at the Windows XP Logo Screen
and that is where it stops. I can see it probe the USB and see it probe the
com ports like normal, but it hangs as mentioned above.

If I remove the CF, I can see all the files okay in a reader. If I copy a
new image to it, it works fine.

Again, this occurs in both DUA and with the Batch file, but randomly.

Any idea why this happens or what file may be getting corrupted? In XPe, do
buffers need to be flushed or anything?

Thanks,
Richard
 
Richard,

Minlogon or winlogon image?

By commit you mean perform commin of EWF, right? This you can do at any time that you want. Actual commit is done during the
gracefull shutdown.
Performs a shut down restart with a 15 second timer.
Click to expand...
If you count 15 seconds from EWF commit then there is no need to it, since commit operation just set one flag in driver and nothing
more. Like I said actual commit happens during the shutdown after file system is closed.

What API command or utility do you use for computer restrart? You must use "gracefull" shutdown. Meaning that if you use some
higher level programs they should be notified that windows is shuting down so that they can close and write their infos.
Look at function ExitWindowsEx also there are native api functions that will skip this shutdown notification.

Regards,
Slobodan
 
It's a Winlogin Image.

Yes, I perform the command "EWFMGR C: Commit" - Sorry, do not have the exact
syntax in front of me but I'm sure that is what it is.

Yes, the timer was for grins, I could do away with it.

Since this is being done from a batch file on a remote laptop, we use the
PSTools, normally all the changes are made without any problem, just
occassionally this happen on reboot, and we are not modifying any OS Files
at all.

We use PSKill to close the applications, Normal Dos copy over the network
(Mapped drive), use PSExec to do the EWFMGR Commit, we Use PSShutdown to
restart the target.

Richard
 
Richard,

I don't know exactly the reason you see the hang but here is a few general comments to your problem:

- If you were with SP2, I'd recommned you to use "-live" switch and not rely on commit at shutdown. But since you are using EWF
on SP1 you don't have this option available.
Did you try upgrading the image to SP2 and run the image on the same hardware?

- Do you have all EWF SP1 QFEs applied to your image?

- From programming side on Win32 in general it is not recommended to use tools like PsKill or similar (a tools that closes a
process by calling TerminateProcess API). You should close your shell application in a proper way (like sending WM_CLOSE/WM_QUIT
message to main message loop of the app, or a terminate named event, or etc.). This is unlikely the cause for your issue now unless
your application relies on some important data on the CF that needs to be committed properly.

- Try to implement all the support steps locally on the device. In other words, with PsExec execute a batch file on the device
remotely. The batch file should do all the steps you mentioned below.
Try to avoid shutting down the device with remote tools (like PsShutdown). As Slobodan pointed out, EWF overlay data commit is
sensible to graceful shutdown.

- Run a stress test on your device. After image boots up, run a local batch script that will commit EWF and reboot the device
gracefully. You can update a log file to add a test timestamp.
Run the device over night and check out if it hangs. If it does, you will see the timing when it happened. This way you may
prove that the EWF commit is the cause of the issue.

- After you write to CF, make sure the flash does not have bad blocks.

- Add /SOS switch to boot.ini to see where the image hangs at boot time.

- Use KD (Kernel Debugger or WinDbg) for the same.
 
It's been running that batch file non stop for every 3 minutes since 7am
this morning, aplly new files, commit, shutdown and reboot, wait 3 minutes
and do it all again. It has not hung one time. I will continue to let it
do it's thing.

Pretty Odd, Wonder if it's a bad CF I get on occasion.

Richard
 
320 cycles and no problem. I'm going to have to write it up as bad compact
flash that has caused the problem.
It should have been repeatable if it was software related.

KM, Slobodan, do you agree?

Richard
 
Richard,

Well.. Do you mean it is running the stress test fine locally on the device?
I mean the batch which is executing all instructions locally?

If it does and the issue has no repro, you should move to use local batch file approach in your support scenario. To avoid using
PsKill and PsShutdown.
And certainly, make sure to test CF which shoed the bug.
 
Back
Top