TeraByte Unlimited

I haven't mentioned this until now because I thought it was a fluke, but it turns out that it happens most of the time (it does not happen in a minority of the attempts) when doing large full backups with 2.97e. I never saw this at all with earlier versions (though the 2.97 releases came so frequently that I didn't have enough experience with any one of them until "e" came along--but this definitely wasn't a problem with 2.96 and earlier), it doesn't happen with smaller full backups (though that's against a different volume), and it doesn't happen with differentials against the same volumes.

Nothing is written to the IFW log, so that's of no use. Nothing is written to Event Viewer. This is Server 2003R2.

It looks like it happens pretty far into the backup (a good hour) in what I think is the transition from the backup to the validation process.

Is it maybe something about "e" that would go away if I revert? The command-line is unchanged:

start /WAIT imagew.exe /b /uy /um /evlogl:1 /d:w1@0x3E7,0x3E8 /f:"F:\IFW_Backups\Image_Full_Monthly_G_H_Drive" /v /hash /exlist=c:\excludes.txt

/logl:10 would write the log as it happens.

What is the access violation? You could send the mini dump if created.

it may be worth running through memtest86+ from memtest.org


"rseiler" wrote in message news:[email protected]...

I haven't mentioned this until now because I thought it was a fluke, but it
turns out that it happens most of the time (it does not happen in a minority
of the attempts) when doing large full backups with 2.97e. I never saw this
at all with earlier versions (though the 2.97 releases came so frequently
that I didn't have enough experience with any one of them until "e" came
along--but this definitely wasn't a problem with 2.96 and earlier), it
doesn't happen with smaller full backups (though that's against a different
volume), and it doesn't happen with differentials against the same volumes.

Nothing is written to the IFW log, so that's of no use. Nothing is written
to Event Viewer. This is Server 2003R2.

It looks like it happens pretty far into the backup (a good hour) in what I
think is the transition from the backup to the validation process.

Is it maybe something about "e" that would go away if I revert? The
command-line is unchanged:

start /WAIT imagew.exe /b /uy /um /evlogl:1 /d:w1@0x3E7,0x3E8
/f:"F:\IFW_Backups\Image_Full_Monthly_G_H_Drive" /v /hash
/exlist=c:\excludes.txt

TeraByte Support wrote:
> /logl:10 would write the log as it happens.
>
> What is the access violation? You could send the mini dump if created.
>
> it may be worth running through memtest86+ from memtest.org

I'll run again with that first and see what it yields. I'll also try to confirm when during the process that it happens, since I think it's pretty consistent.

That is the access violation. It's always all zeros. No mini dump was created, but isn't that only for Windows crashes? This was just an application error/crash.

I have more clarity on when the problem occurs. It's not between backup and validation but right after when the backup of the first volume completes and the second begins. Could something in 2.97x relate to this somehow?

Enabling max logging didn't reveal anything interesting but just showed how far it had progressed (it's one of the things, in addition to keeping a close eye on the GUI, that told me I wasn't anywhere near the validation stage yet--I was fooled initially by the item progress bar).

So, between tests this month and last, 2.97e failed in the same place about 7 of 8 times. Absent anything else to do for now, I went back to 2.96 so that it would complete.

you could try removing /hash or /exlist

by volume, you mean in an extended partition, or just the next partition?

"rseiler" wrote in message news:[email protected]...

I have more clarity on when the problem occurs. It's not between backup and
validation but right after when the backup of the first volume completes and
the second begins. Could something in 2.97x relate to this somehow?

Enabling max logging didn't reveal anything interesting but just showed how
far it had progressed (it's one of the things, in addition to keeping a
close eye on the GUI, that told me I wasn't anywhere near the validation
stage yet--I was fooled initially by the item progress bar).

So, between tests this month and last, 2.97e failed in the same place about
7 of 8 times. Absent anything else to do for now, I went back to 2.96 so
that it would complete.

@0x3E7,0x3E8 represent two logical drives in an extended partition.