Main Area and Open Discussion > General Software Discussion

Outlook 2003 - PST file corruption. Is it X1 ?

<< < (4/8) > >>

Carol Haynes:
The problem with ScanPST is that it simply truncates the PST file at the first error (as far as I can tell). So there is a big potential to lose emails.

Rather than using ScanPST initially try copying all your emails to a new PST file. (Create a new PST file from the File menu and then copy the folders from the Personal Folders tree).

If you have already used ScanPST you can check the file size before and after to estimate how much data has been lost in the repair. (The original is still there as a .BAK file). You can try and recover manually as above by closing Outlook and renaming the backup to a new name with a PST extension and then restart Outlook and use File > Open to load the original PST file as an extra set of folders).

Here are a few useful articles ...

http://www.slipstick.com/problems/scanpst.htm
http://office.microsoft.com/en-us/assistance/HA010563001033.aspx

and some other options ... (not tried them though ... beware)

http://www.oemailrecovery.com/repair-pst.html
http://www.freedownloadscenter.com/Best/pst-file-repair.html
http://searchexchange.techtarget.com/tip/0,289483,sid43_gci1065241,00.html

JavaJones:
Actually scanpst *increased* the size of the file, lol. It also produces a log which shows some stuff which may be enlightening as to what it's doing. I don't think it just truncates though. At least I hope not. That's terrible.


--- ---Microsoft (R) Inbox Repair Tool
Copyright (C) Microsoft Corp 1995-1996. All rights reserved.

**Beginning NDB recovery

  **Attempting to open database

  **Attempting to validate header

  **Attempting to validate AMap

  **Attempting to validate BBT

  **Attempting to validate NBT

  **Attempting to validate BBT refcounts

    ??BBT entry (6A6D28) has different refcount in RBT (3 vs 2)
    ??BBT entry (10BAE9C) has different refcount in RBT (3 vs 2)
    ??BBT entry (10BAFC8) has different refcount in RBT (3 vs 2)
    ??BBT entry (10E94C4) has different refcount in RBT (3 vs 2)
    ??BBT entry (10EE17C) has different refcount in RBT (3 vs 2)
    ??Couldn't find BBT entry in the RBT (22782B4)
    ??Couldn't find BBT entry in the RBT (22EE81C)
    ??Couldn't find BBT entry in the RBT (22EEF40)
    ??Couldn't find BBT entry in the RBT (22EEF46)

  **Attempting to validate header NID high-water marks

**Beginning PST/OST recovery

  **Attempting to recover all top-level objects

      !!Folder invalid high-water-mark (nidi=6606, nidiHigh=A97D)

      !!Search folder invalid high-water-mark (nidi=9032, nidiHigh=B600)

  **Attempting to walk all folders

      !!Hierarchy Table for 122, row doesn't match sub-object:
        irow = 0, RowID = 2223

  **Attempting to locate any orphaned folders/messages

  **Attempting to check top-level objects for consistency

      ??Deleting SDO

  **Updating folder hierarchy

**Attempting to fix original file

  **Attempting to copy back BBT

  **Attempting to copy back NBT
- Oshyan

Carol Haynes:
It might help if there was some explanation of BBT, RBT and DDO - what is that supposed to tell a user ...

I almost never look at the log (even if there was a problem) 'cos it makes no sense to the general user - and there is no point asking MS for support.

I presume the PST file structure is a basic database type structure with variable record contents (depending on whether the record is an email, calendar entry etc).

I can't for the life of me understand why the files seem to be so prone to corruption without the host software even noticing!

By the way PST files over 2Gb are not recommended because they get corrupted - this certainly was a problem. I'm not sure if it is fixed in Outlook 2003. If you have over 2Gb of data in your file it must take Outlook an age to load up and searching for anything (without X1) must be horrendously slow!

JavaJones:
I can't for the life of me understand why the files seem to be so prone to corruption without the host software even noticing!
--- End quote ---

lol, yeah I've wondered this for some time now as well.

Interestingly I re-scanned both the original .bak file and the fixed one, and it turns out the only change made was actually *increasing* the number of known messages by 1. So it actually recovered one message. My lord, it actually worked for its intended purpose! :D

- Oshyan

Carol Haynes:
Shock and Awe !

Navigation

[0] Message Index

[#] Next page

[*] Previous page