Error: Access Violation

[BLLuten]

I have a Western Digital WD5000C032 attached via USB2 to an Dell Optiplex 755 running Windows Vista Enterprise, which is producing the following:

Error: Access violoation at 0x00401F3E (tried to write to 0x03220FFC), program terminated.

The recovery run progress information:
. Elapsed time: 13h 38m 22s
. Filesystem type: Not known yet
. Raw scan: Full - identifying data (99%)
. Located 0 files in 0 directories

The volume map shows data fragments and filesystem structures that seem consistent with what we're after, but this is the second crash like this I've had. I've attached the end of the logfile.

I am running ZAR 8.3 build 19 from within an account that is a member of the local administrators group. User account control kicks in on ZAR launch, as expected, and I allow the application to run. I have not tried to explicityly launch ZAR via "Run as Administrator", which for some programs, running on Windows Vista, I have discovered does make a difference.

Sophos Antivius 7.0.7 is running on this system, an I have excluded this drive letter from the on-access scan settings, but not turned off on-access scanning, which is set to on-read.

Active@ Partition Recovery 5.1 and Active@ File Recovery 7.1 have not presented anything useful to restore from this drive. I'm going to try Restorer 2000 next.

~
Background:

This drive came from a user who had problems after a strange shutdown of his system. Attaching this drive initially to my computer, indicated above, would cause a lock up of any standard Windows application trying to access the drive. I'm thinking something happened to the FAT table at this point, as I'm assuming this drive was FAT32.

Since it was locking up my Windows box on standard access attempts, I thought I'd plug it into a Mac iBook G3 (OS X 10.4.9), where the drive also didn't behave. I also believe the Mac tried to "fix" or initialize the drive, without prompting, which has changed the directory structure information (there's now a .trashes folder) from what we expect. The drive now doesn't lock up my Windows systems when attached, though.

What's also interesting is that the disk properties of this disk now appear with a used space of 64.8-GB (again what we're looking for), but the properties for all the files in the directory tree only total 293-KB.

[Alexey V. Gubin]

Any chance you try the latest one, http://www.z-a-recovery.com/zar-83-027.exe ? At 1GB size, looks like it should be fast enough.

[BLLuten]

Giving ZAR 8.3 build 27 a try now. Trying a scan on just the first 100-GB of the drive, to see what we get. Depending on the result, I may run a scan of the whole drive overnight, which is what I've done on my previous attempts.

P.S. Restorer 2000 didn't find anything restore worthy, which is the same result I got from Active@ Partition (& File) Recovery.

The ZAR volume map is the only thing that gives me hope that there is something recoverable :), if the program simply wouldn't crash. :confused:

[Alexey V. Gubin]

Any news as of now?

[BLLuten]

The 100-GB (20%) pass showed recoverable files, so I ordered my copy, and I'm waiting for a full pass to complete, which is at 95% now, with just over 13 hours elapsed. I expect to be recovering files after lunch (PST; 90 minutes from now), and will report back with our results. :cool:

[BLLuten]

The application crash occurred again. There must be something at the end of this drive that ZAR doesn't like.

The volume map scale is 243-MB per map block and there are four blocks, starting 8 blocks from the end, of filesystem structures and data fragments. The rest of the volume map shows nothing interesting, except for the first three rows, where we expect our files for recovery to be.

Since the volume map list nothing interesting beyond the first 15% of the drive, except at the end, I'm going to limit the next scan to this and expect to be able to recover files, since it was promising when I scanned the first 20% in demo mode.

I decided to scan just the last 5-GB of the drive, where the volume map shows the four interesting blocks, but ZAR reports "...no files on volume" (logfile attached).

P.S. It would be nice if the "define volume manually" had an option for gigabytes, in addition to megabytes and sectors. :)

[Alexey V. Gubin]

I'm not quite sure that it is in the "end of a drive". There may be a problem with a directory structure, something that prevents proper reconstruction. Bad thing is that quick scan feature is not available for FAT filesystem, so every test run is... how long? ten hours? So, for now the only thing I can do is to add detailed progress logging near the point where it crashes; hopefully, this allows to isolate the problem.

[Alexey V. Gubin]

Check a directory C:\Program Files\ZAR\Autosave
For a successful run, two files should be recorded. The file names are based on a time when the file is stored. First file is recorded when the "raw scan" is complete. Second one is recorded when the analysis is fully complete. Of the two files, first one is smaller.

Try to identify the two save files from the latest crashed "full" run. Are both files present? If yes, try loading them (in turn), to see if it crashes immediately on loading.

[BLLuten]

The crashed runs don't appear to have a .zar file in the autosave folder.

P.S. I would concur that the directory structure must be really messed up. Could the data at the end of the drive be a copy of the FAT? I don't recall how the file systems are laid out on the disk.

[Alexey V. Gubin]

We've reviewed the first log again, and found that
The last thing we know worked properly was first stage filter. It should then start the validation module, but in the log comes a set of records consistent with an abnormal shutdown in progress. The validation never starts. Between these points are
- Second stage filter
- Autosave
- Interface operations (wizard page change)
An error message you provide suggests the fault is either in autosave, or in interface. SSF error would have produced a different message. So we need you to check if autosave worked or not.

[Alexey V. Gubin]

The crashed runs don't appear to have a .zar file in the autosave folder.

Are you sure that there are NONE of the two files recorded? I'd expect one of the two written anyway, since it is done earlier in process than it crashes.

[BLLuten]

Here's the list of of files in the autosave folder:

ZAR-2008-02-07 15-56-15.zar (false start, I specified 10-GB instead of 100)

ZAR-2008-02-07 17-36-02.zar
ZAR-2008-02-07 17-37-03.zar (successful 100 of 500-GB scan, I believe)

ZAR-2008-02-08 13-10-03.zar
ZAR-2008-02-08 13-30-39.zar
ZAR-2008-02-08 13-31-27.zar

Tpday's application crash is logged in my event log at 2008-02-08 12-16-00.

Faulting application zar.exe, version 0.0.0.0, time stamp 0x2a425e19, faulting module zar.exe, version 0.0.0.0, time stamp 0x2a425e19, exception code 0xc0000005, fault offset 0x00001f3e, process id 0xfd8, application start time 0x01c86a1ad015b88a.

Yesterday's crash is logged at 2008-02-07 09-16-22.

There don't appear to be any autosave files around the time of these crashes. The date modified field of these files matches the filename date stamp.

What else can I provide you with. :)

[Alexey V. Gubin]

Rather interesting. So the plan is:


We build a version with a little more logging.
You install it, and disable autosave. This is done in "Advanced Configuration", "General".
You then run it against the full 500GB drive.
If the problem is with autosave, then it should work fine.
If the problem is with something else, it crashes, and we have a more detailed trace in the log file.An update will be ready in about an hour and a half from now.

[BLLuten]

Sounds good. I should be able to run it overnight. :cool:

[Alexey V. Gubin]

Download at http://www.z-a-recovery.com/zar-83-028.exe, install and start.
Click "Advanced Configuration".
Close to the bottom of a configuration window, clear "Enable autosave".
Click OK to close configuration.
Proceed to scan a full drive same as previously.I then need a new log file if it still fails.

[BLLuten]

OK, installed build 28. FYI: I get a Program Compatibility Assistant alert after installing this on my Windows Vista Enterprise system. This was true of build 27 as well. I don't believe build 16 had this issue.

Unchecked "Enable autosave".

Starting a full scan now. We'll see what happens in about 14 hours. :)

P.S. We've already been able to recover the bulk of what was needed. There is still one folder that would be nice to discover.

[Alexey V. Gubin]

As I recall the PCA warning does not appear if you uninstall the older version first. The program functions properly regardless of this, as far as I know.

See you in 14 hours :)

[BLLuten]

Same error "Error: Access violation at 0x00401F3E (tried to write to 0x020000FFC), program terminated. Log file attached.

Anything else you'd like me to try? :)

[Alexey V. Gubin]

Nothing at this time - working on it.

[BLLuten]

I guess this concludes our fun with this drive then as it will be reformatted Monday and put back into use.

Thanks. :)

[Alexey V. Gubin]

I find it sad somehow, but so be it. If you want a refund, send me a private message with your first and last name, or an order reference number. Sorry we did not work it out.

[BLLuten]

If you're interested in more experimenting with this drive I could probably delay putting it back into use for a few days.

I certainly don't need/expect any refund. ZAR actually recovered quite a bit. This drive somehow got into rather bad shape. Before putting it back into service I plan to run an extensive diagnostic on it. :)

[Alexey V. Gubin]

I doubt a few days will help much. I'd say reformat.

[BLLuten]

Will do. Thanks for your help. :)