Link to home
Start Free TrialLog in
Avatar of jdcreece

asked on

PST Not a Valid Personal Folders File

A client had a Server 2000 Terminal server go down (2 of 3 drives failed RAID 5.) They did have one recent full and incremental  Veritas backup. I have successfully restored all of the user data plus system state (using NT backup and restore) to a new Server 2000 VM (VMware.) I decided to restore to a VM instead of a physical machine for obvious reasons. EVERYTHING works great, even their old software that was developed for them in the early eighties, except one very important .pst file. It was created in either office 97 or 2000 originally. I have tried scanpst, pst-repair-t, Stellar Phoenix, Kernel PST, OnTrack Data Recovery and probably a few others. They all either say it's not a valid file or go through the motions of repairing the file but the end result is absolutely nothing being recovered. No messages, no files, no folders, no contacts. The pst file in question is 1.6GB. So, the size shouldn't be an issue for 2000. I'm not so sure about 97 though. Thanks for any help.
Avatar of chcw
Flag of Hong Kong image

Have you tried

Advanced Outlook Repair

Actually Outlook recovery tools perform rather differently, here is a comprehensive comparison chart 
Avatar of jdcreece


No dice. After waiting 1.5 hours for the software to run it said it recovered 8 items out of a 1.6 gb pst file and it created a "repaired" pst of only 256k. I'm really quite surprised I'm having this much trouble finding a solution.
FYI - I went ahead and opened the "repaired" pst and it's completely empty.
What is the repair log? Can you post it?
I don't think I saved it. I'll run it again and post it.
Avatar of Davis McCarn
If SCANPST said it finished correctly, you need to import it into a working Outlook.  Because the SID will have changed, it will open as empty because it thinks all the stuff belongs to the old SID.
If SCANPST doesn't finish, tell me; otherwise do File -> Import and point the wizard to the old PST after the email account is working.
Thanks for the comments. I extracted just the pst from the backup again to ensure I have a "clean" copy and saw red exclamation marks when I got to the user's application data folder. Then received errors stating that the files restored were from an incomplete or bad backup. Strange that originally the rest of the user data and system state, and even software restored without issue.

1. Can this pst be repaired? scanpst won't recognize it

2. Why is just the pst damaged? Maybe because the file was open during back up?
I'll bet Outlook was open when the backup was done and, on Server 2000, the PST can't have been backed up because it was open.  Have you tried the Archive?
I haven't tried the archive. The one with the same time stamp as the Outlook.pst is only 2MB.  
The archive1 modified the same time as the corrupt outlook and is not recognized as a valid personal folders file. There is an archive from 2005 that does contain data. It's a little old though! Any more suggestions would be appreciated. I'm currently running some data recovery software on the external back up drive to see if I can find any more bkf files to restore from. It's starting to look like I might be SOL.
It seems that the BKF file has some problems, although the symptom is a little strange. Also if you can pos the repair log by Advanced Outlook Repair, that will also be helpful. If you have hexidecimal editor such as WinHex and UltraEdit, you can also open the raw PST file and investigate the raw data inside it. An experienced data recovery engineer can find clues based on such a raw data analysis. As for normal computer users, if you find there are a lot of zeros inside the file, then that also mean the parts that are filled with zeros are beyond recovery.
Have you searched for other PST files?
Normally, any file in use is locked and cannot be backed up. What I smell are two sxabarios; Outlook was opened while the backup was happening or Veritas got past that but blew out when an automatic send/receive happened.  Either way, I suspect you are SOL, too.
chcw I have a sneaky suspicion that you work for that software company ;) I really don't have time to play with software I'm not familiar with. If I do have time I will post the data you want. I have performed several data recoveries over the years and heard people say that you can work wonders with raw data and an editor, but they never say how. I know how to use an editor to read pieces of information but how do you rebuild it?

DavisMcCarn FYI - Veritas (now Symantec Backup Exec) does allow for backup of files while in use if the feature is turned on. It's not usually turned on by default and it certainly wasn't in this case. I don't know if was even a feature on this 10 year old version. I have been focused on this single pst because I was certain it was the correct and/or most current one, but one should never assume anything. I will do some more searching. I fear that your analysis may be correct.

...thanks for the help...
I have no relationship with any software company that provides Advanced Outlook Repair, UltraEdit or WinHex. Instead, I just try to figure out what is your problem and how to solve it, based on my experiences in analyzing a lot of PST files with Advanced Outlook Repair, UltraEdit and WinHex, which I have used in the past and recovering thousands of PST files from customers successfully.

Without the log file and not be able to see any of the raw binary data, even if I want to help you, I have no clues. Actually after you open the raw file with UltraEdit or WinHex by yourself, you will get some feelings of what the corruption is, at your first glance, even if you do not know the format of the file and cannot rebuild it by hand.
Another possiblity is that your BKF file has some corruptions, but the clue that you said other files can be recovered successfully make this not likely happen. Actually, simply based on your description and some clues that is really hard to diagnose and determine what's wrong with your system accurately, not to mention there are no further information provided.
I think that is pretty well established that the issue is a corrupt pst due to being open during the backup process. Now how do we go about repairing it? It seems that most of the available pst recovery software is not able to fix it. I'm going to run another scan with AOR and wait another 1.5 hours for it to finish. Assuming that I will not get far with that method again I will need to attempt to "manually" recover the data using the editor as a tool. Here is a piece of the 1.6GBfile. The entire text string says "this is padding" which isn't normal in my experience. How do you go about repairing it with the editor?
"The pst file in question is 1.6GB. So, the size shouldn't be an issue for 2000. I'm not so sure about 97 though."

In 97 and 2000 the Maximum PST size is 2GB.
Quite often you see corruption after 1.5GB

What you can try doing is opening the PSt in Office 2010 if you have access to it.
Sometimes it can repair a damaged PST.

IN 2007 and 2010 you could also create a New UNicode PST, that supports files up to 20GB.
Once created try importing the damaged PST into the new one.

Other than those options, unless you want to pay big $$ for data recovery, the only thing left would be to hope that there was another back-up of the PST anywhere.

My thought here though would be that the PST was likely corrupt before it was even restored. (Have a look at it and see when the last time it was modified)
Might have the person verify that they are 100% sure thats the PST that they used before and it was working before.
Quite often I see users swear that "This is My PST and I cant open it", only to find out they created a New One and it was lcoated in the Documents Folder and not even anywhere close to the network location where they were supposed to be saved.

I am certain that this is the correct pst. After searching and finding other pst files this is the only one that has been modified since 2005. There is no other recent back up. The data recovery software we are using is the same as what many well known data recovery houses use.

chcw I have attached a copy of the AOR and SCANPST logs.

It's great to see the raw data inside your PST file. Now everything is very clear.

If you open a health PST file, you will find !BDN signature(PST file is stored in NDB format in low level) in the first four bytes of the file, with the remaining contents filled with different binary bytes, not easy to decode but at least you can believe there are something inside them.

Below is using UltraEdit to view the header of a healthy PST file.
 User generated image
However, in your PST file, the snapshot of your file contents are filled with all "This is padding!" texts. If all the file is filled with such a text, obviously they are invalid and cannot contain any valuable information. How can you expect thousands of repeated "This is padding!" can be decoded to different kinds of emails in your PST file? So actually your PST file does not contain any recoverable data at all.

As far as I know, some tools will put such a string "This is padding!" when they cannot read data from the source disk, maybe due to hardware failure or other reasons. So, if you do confirm your PST file is completely filled with "This is padding!", then give up the PST file immediately. What you need to do is to find when and how the original contents of the PST file are replaced with "This is padding" strings. And if possible, find the original location the last time where you have stored the correct version of the PST file, not the one filled with "This is padding!"
Apparently, the "This is Padding!" string is inserted when there are read errors, either during the backup or restore operations so it isn't that the PST was open; it's that the array was already failing when the backup was created (assuming you're not getting errors from the tape?).
You don't perchance, have another backup from 1-3 months earlier, do you?
If not; since you already delved into the world of hex editing, mark all of the blocks with "This is Padding! <cr><lf>", fill them with 00 (zeroes), pray to Bill Gates, and try SCANPST again.  0's are generally the least troublesome when rebuilding a binary database and I can easilly see some pointer jumping into the bad data area causing SCANPST to make a nasty left turn.  Try to use the SCANPST from Office 2003 if you can.
I appreciate all of your help. I'll be looking at this file later this afternoon and post back what I find. Thanks!
How can you expect thousands of repeated "This is padding!" can be decoded to different kinds of emails in your PST file?

How can I NOT expect it to be recoverable? Why is it not recoverable?

I found a .bak file that has up until 4-2009. Getting closer...
The beginning of the file does have a BDN line. I tried adding zeros everywhere and the pst was unrecognizable to scanpst or outlook. I then tried zeroing out just one line in the middle of the file and was able to run scanpst but nothing was recovered.
Can some please explain in detail why the file isn't recoverable? At least a link that provides a thorough explanation.
Avatar of Davis McCarn
Davis McCarn
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
So the pointers are kind of like the MFT on a hard drive? That makes much more sense now. When the MFT is damaged the data is still sitting there and can be easily extracted with the right software, but with the pointers being damaged the data isn't easily recovered because the pst is turned into a database file that's unreadable. Thanks a lot for helping me out and not being patronizing. It's great to get answers, it's better to understand them.