Windows Vista Tips

Windows Vista Tips > Newsgroups > Windows Live Mail > Message Opening Problem

Reply
Thread Tools Display Modes

Message Opening Problem

 
 
Jon
Guest
Posts: n/a

 
      01-31-2008
When I double click on a message to open it, a different message opens, not
the one I selected. It seems as if the messages database index is out of
sync. So far, I have only noticed the problem in one folder (which has about
1,000 messages). The messages in the other folders open correctly.
Is it possible to reindex or something to fix the problem?
By the way, all of my messages were recently imported from another computer.
I used WLM import and export to move the messages from one computer to
another - don't know if this has anything to do with it.
--
Jon
 
Reply With Quote
 
 
 
 
Peter.R
Guest
Posts: n/a

 
      01-31-2008
Hi Jon.

When importing a lot of messages, WLMail has a lot of indexing to do
indexing the imported messages in the "Imported items" folder. I found
that if the messages are then moved too soon (before the indexing is
complete), things can go awry. Also, dragging folders from one storage
folder into another storage folder is not a good idea due to the way the
indexing works.

There is also a bug in the current version of WLMail (1606) that causes
the "Quick views" to break when a storage folder is deleted.

So there are several options available that might correct your problem,
some more dramatic than others, so you might want to backup/export all
your messages first. From simplest to most dramatic, they are:

1. To rebuild the Quick Views from scratch, you should delete the
registry Value "SearchFolderVersion" under
HKEY_CURRENT_USER\Software\Microsoft\Windows Live Mail. This will cause
WLMail to rebuild its Quick view data store when it is next started.

2. Delete the database file "Mail.MSMessageStore" after first ensuring
that its backup is in place. The backup must be in place to avoid a full
database recovery. When the database file is deleted when its backup is in
place, WLMail will replace it from the backup when it is next started. If
the backup is not in place, just leave WLMail open for a few hours and
check again later. The backup should be in place unless a database
compaction has been performed very recently.

The database file "Mail.MSMessageStore" is found in WLMail's Storage
Folder. This Storage Folder in its default location is a hidden folder, so
ensure "Show hidden files and folders" is checked under Folder Options in
Windows Explorer. To find the location of your message store, go to
Tools->Options...->Advanced [tab]->Maintenance->Store Folder. The default
locations are -

Vista: %localappdata%\microsoft\windows live mail
(C:\Users\<Windows user
account>\AppData\Local\Microsoft\Windows Live Mail)

XP: %userprofile%\local settings\application data\Microsoft\windows
live mail
(C:\Documents and Settings\<windows user account>\Local
Settings\Application Data\Microsoft\Windows Live Mail)

The backup of the database file "Mail.MSMessageStore" is found within the
Storage folder in the folder Backup\new. This backup database file is
also
called "Mail.MSMessageStore".

3. Compact the database. This might seem a simple thing, but when there
are problems with the database, a full database recovery can ensue, which
causes all messages to end up in folders within "Recovered items" under
"Storage folders".

To manually compact the database, in WLMail, go to
Tools->Options...->Advanced [tab]->Maintenance [button]->check the option
"Compact the database on shutdown every 'n' runs" and change the value 'n'
to '1'. Then exit WLMail and select "Yes" when asked to "Recover unused
disk space". If the database compaction process fails to start, open
WLMail again and immediately close it, as this is a workaround for that
bug.

4. Force a full recovery of the database. This will cause WLMail to
move all messages into folders within "Recovered items" under
"Storage folders", and any messages left on your POP e-mail server's inbox
will be re-downloaded unless the server has an option to prevent this
(such as Gmail). As all the messages are moved into "Recovered items",
they will be re-indexed at that location, so don't be in a hurry to move
them to another folder (wait until the re-indexing is complete). If, after
moving them, you delete the "Recovered items" folder or any other storage
folder in WLMail build 1606, you will need to fix the broken "Quick views"
as explained in method 1.

To force a full recovery of the database, there are several methods to
choose from, which will cause the full database recovery when WLMail is
next started -

a) For a while after compacting the database as explained in method
3, the backup of the database file "Mail.MSMessageStore" will *not* be in
place. When it is *not* in place, deleting the database file
"Mail.MSMessageStore" within the Message Store of WLMail will cause a full
database recovery when WLMail is next started.

b) Delete the database file "Mail.MSMessageStore" within the
Message Store of WLMail, and also delete the backup of the database file
"Mail.MSMessageStore".

c) Delete the registry Value 'DatabaseVersion' under the key:
HKCU\Software\Microsoft\Windows Live Mail.

5. After backing up/exporting all messages, and accounts, rename your
Windows Live Mail Message Store folder. When WLMail is next started, it
will recreate the Message Store folder. Then import your accounts and
messages into WLMail. Messages can also be imported directly from your old
renamed Message Store by dragging them onto the WLMail interface, or by
using the File->Import->Messages->Windows Live Mail option and pointing
it to your old renamed Message Store folder. Or maybe you would need to
import an older backup if you find some messages are actually corrupted
(most likely it was just the database though).

At least one of these options will fix the problem I am sure, but if you
report back with the results, other people can benefit from your
experience.
--
Cheers,
Peter
(Windows Vista Home Premium with Windows Live Mail 12.0.1606)
"There are more things in Heaven and earth, Horatio, than are dreamt of in
your philosophy." - Shakespeare
---------------

"Jon" <> wrote in message
newsDD6A3C7-7A93-48EA-90F6-...

> When I double click on a message to open it, a different message opens,
> not the one I selected. It seems as if the messages database index is
> out of sync. So far, I have only noticed the problem in one folder
> (which has about 1,000 messages). The messages in the other folders
> open correctly.
> Is it possible to reindex or something to fix the problem?
> By the way, all of my messages were recently imported from another
> computer.
> I used WLM import and export to move the messages from one computer to
> another - don't know if this has anything to do with it.
> --
> Jon


 
Reply With Quote
 
Ron Sommer
Guest
Posts: n/a

 
      01-31-2008
Why are you saying that WLM not doing the compaction is a bug if the
compaction doesn't start on the first close after changing the number to 1?


After the compaction, change value 'n' back to 100.
I don't think that you want a compaction on every close.
--
Ronald Sommer

"Peter.R" <> wrote in message
news:eZBGlg#...
snipped>
> To manually compact the database, in WLMail, go to
> Tools->Options...->Advanced [tab]->Maintenance [button]->check the option
> "Compact the database on shutdown every 'n' runs" and change the value 'n'
> to '1'. Then exit WLMail and select "Yes" when asked to "Recover unused
> disk space". If the database compaction process fails to start, open
> WLMail again and immediately close it, as this is a workaround for that
> bug.
>

snipped

 
Reply With Quote
 
Peter.R
Guest
Posts: n/a

 
      01-31-2008
What I said was "If the database compaction process fails to start, open
WLMail again and immediately close it, as this is a workaround for that
bug."

It is a known bug that WLMail sometimes fails to start the compaction
process, whatever the number at "Compact the database on shutdown every
'n' runs" is set to. The known workaround for this is to restart WLMail
and immediately close it again when 'n' set to 1. Thus, if after setting
the number to 1, WLMail fails to start the compaction process, it is
evidence of that known bug. Apply the workaround to get the database to
compact. If you leave 'n' set as '100', you will be waiting for another
100 shutdowns of WLMail before you are again offered the choice to
"Recover unused disk space" after a database compaction fails to start.

I posted a comprehensive assessment of this bug here in November last
year at news: (see a copy below^^)
and it was bugged and validated at Microsoft Connect around the same time.

Actually, I tested the bug and the workaround as I wrote my previous post,
and as expected, WLMail did fail to compact on the first close after
setting that number to 1. The database compaction failed to start because
I had been using Newsgroups for a while etc., but the workaround worked as
expected.
----------

^^After upgrading to WLMail 12.0.1606 (same bug occurred in 1365) I
continued to experience the error "The folder is currently in use by
Windows Live Mail or by another application" when I opt to "Recover unused
disk space" (compact the database). Initially I had assumed it was my
antivirus program (Avast) or my Search Indexer, however I found the error
still occurred after disabling both my antivirus and search indexer. So I
investigated what is remaining locked within the Message Store folder, and
by what. As 'Screenshot_1'
(http://img248.imageshack.us/img248/7...enshot1mv2.png) shows,
whenever I got this error message, Unlocker indicated that three files
were locked by WLMail, namely tmp.edb, edb.log, and Mail.MSMessageStore.

Now, upon further investigation, I realised that the file tmp.edb is
created when WLMail is started, and is *normally* deleted as WLMail is
closed. However, in *every* instance where this compacting error occurred,
I found that the file tmp.edb was not deleted when WLMail was closed (as
can be seen in 'Screenshot_2'
(http://img266.imageshack.us/img266/9...enshot2yi6.png)).

I used 'EndItAll' to close or kill all unnecessary programs and processes
before opening WLMail, but this problem still occurred.

I noticed also that the file tmp.edb is recreated during the database
compaction process, but this tmp.edb file increases in size throughout the
compaction process. So it would seem that this recreation of tmp.edb
cannot occur whilst the old tmp.edb (128KB size) remains within the
Message Store folder. Moreover, once the error message was cancelled, I
found that those files are were no longer locked, so it seems that it is
the initiation (beginning with the opt in question) of the compaction
process itself that is locking those files.

Now, I also found that even when no database compaction is due, as WLMail
closes, the file tmp.edb was often not deleted as it should be, however it
was not locked. The question is then, why was the file tmp.edb not always
deleted as WLMail closed? If I opened WLMail and immediately closed it
again without doing anything (such as sending/receiving messages, opening
messages, composing messages etc.), I noticed that tmp.edb *was* deleted
(thus database compaction succeeded). Interestingly, when the tmp.edb file
was not deleted as WLMail closed, WLMail deleted it and then recreated it
as WLMail was restarted. The file tmp.edb *was* also deleted after only
downloading e-mails, and newsgroup headers, but when several (not sure
how many it takes) newsgroup message bodies were downloaded and read,
tmp.edb usually failed to be deleted as WLMail was closed. There may be
other contributing factors, but as yet I have not narrowed them down.

Thus, one workaround for this bug is to close WLMail immediately after
opening it, whilst another may be to not use newsgroups, or not to
download news bodies before closing WLMail. Doing this allows the database
compaction to succeed because the tmp.edb invariably is deleted when
WLMail is closed in this manner.

Compacting the database did not rectify the problem.
Doing a full uninstall of WLMail (deleted program files*, registry keys**,
renamed Message Store folder***) before reinstalling did not rectify the
problem (although initially it did appear to).

*C:\Program Files\Windows Live\Mail
**HKEY_CURRENT_USER\Software\Microsoft\Windows Live Mail
***C:\Documents and Settings\Peter\Local Settings\Application
Data\Microsoft\Windows Live Mail.

--
Cheers,
Peter
(Windows Vista Home Premium with Windows Live Mail 12.0.1606)
"There are more things in Heaven and earth, Horatio, than are dreamt of in
your philosophy." - Shakespeare
---------------

"Ron Sommer" <> wrote in message
news:ujlfqj$...

> Why are you saying that WLM not doing the compaction is a bug if the
> compaction doesn't start on the first close after changing the number to
> 1?
>
>
> After the compaction, change value 'n' back to 100.
> I don't think that you want a compaction on every close.
> --
> Ronald Sommer
>
> "Peter.R" <> wrote in message
> news:eZBGlg#...


> snipped>
>> To manually compact the database, in WLMail, go to
>> Tools->Options...->Advanced [tab]->Maintenance [button]->check the
>> option "Compact the database on shutdown every 'n' runs" and change the
>> value 'n' to '1'. Then exit WLMail and select "Yes" when asked to
>> "Recover unused disk space". If the database compaction process fails
>> to start, open WLMail again and immediately close it, as this is a
>> workaround for that bug.
>>

> snipped


 
Reply With Quote
 
Ron Sommer
Guest
Posts: n/a

 
      01-31-2008
Thanks for the explanation of the bug.

Why did you say, "If you leave 'n' set as '100'"?
'n' was set to 1 to get the compaction to occur.
If you leave 'n' at 1, won't WLM want to compact at every shutdown?
--
Ronald Sommer

"Peter.R" <> wrote in message
news:...
> What I said was "If the database compaction process fails to start, open
> WLMail again and immediately close it, as this is a workaround for that
> bug."
>
> It is a known bug that WLMail sometimes fails to start the compaction
> process, whatever the number at "Compact the database on shutdown every
> 'n' runs" is set to. The known workaround for this is to restart WLMail
> and immediately close it again when 'n' set to 1. Thus, if after setting
> the number to 1, WLMail fails to start the compaction process, it is
> evidence of that known bug. Apply the workaround to get the database to
> compact. If you leave 'n' set as '100', you will be waiting for another
> 100 shutdowns of WLMail before you are again offered the choice to
> "Recover unused disk space" after a database compaction fails to start.
>

snipped>
> "Ron Sommer" <> wrote in message
> news:ujlfqj$...
>
>> Why are you saying that WLM not doing the compaction is a bug if the
>> compaction doesn't start on the first close after changing the number to
>> 1?
>>
>>
>> After the compaction, change value 'n' back to 100.
>> I don't think that you want a compaction on every close.
>> --
>> Ronald Sommer
>>
>> "Peter.R" <> wrote in message
>> news:eZBGlg#...

>
>> snipped>
>>> To manually compact the database, in WLMail, go to
>>> Tools->Options...->Advanced [tab]->Maintenance [button]->check the
>>> option "Compact the database on shutdown every 'n' runs" and change the
>>> value 'n' to '1'. Then exit WLMail and select "Yes" when asked to
>>> "Recover unused disk space". If the database compaction process fails
>>> to start, open WLMail again and immediately close it, as this is a
>>> workaround for that bug.
>>>

>> snipped

>

 
Reply With Quote
 
BillD
Guest
Posts: n/a

 
      02-01-2008
Great explanation!! I have my shortcut set to open WLM directly to one of
the beta newsgroups and even though WLM downloads new headers, the
workaround (set to 'n' to 1, open, close) works every time. Maybe a fix with
the next update, but the workaround is not too much of a hassle. Thanks for
you explanation.

BillD

"Peter.R" <> wrote in message
news:...
> What I said was "If the database compaction process fails to start, open
> WLMail again and immediately close it, as this is a workaround for that
> bug."
>
> It is a known bug that WLMail sometimes fails to start the compaction
> process, whatever the number at "Compact the database on shutdown every
> 'n' runs" is set to. The known workaround for this is to restart WLMail
> and immediately close it again when 'n' set to 1. Thus, if after setting
> the number to 1, WLMail fails to start the compaction process, it is
> evidence of that known bug. Apply the workaround to get the database to
> compact. If you leave 'n' set as '100', you will be waiting for another
> 100 shutdowns of WLMail before you are again offered the choice to
> "Recover unused disk space" after a database compaction fails to start.
>
> I posted a comprehensive assessment of this bug here in November last
> year at news: (see a copy below^^)
> and it was bugged and validated at Microsoft Connect around the same time.
>
> Actually, I tested the bug and the workaround as I wrote my previous post,
> and as expected, WLMail did fail to compact on the first close after
> setting that number to 1. The database compaction failed to start because
> I had been using Newsgroups for a while etc., but the workaround worked as
> expected.
> ----------
>
> ^^After upgrading to WLMail 12.0.1606 (same bug occurred in 1365) I
> continued to experience the error "The folder is currently in use by
> Windows Live Mail or by another application" when I opt to "Recover unused
> disk space" (compact the database). Initially I had assumed it was my
> antivirus program (Avast) or my Search Indexer, however I found the error
> still occurred after disabling both my antivirus and search indexer. So I
> investigated what is remaining locked within the Message Store folder, and
> by what. As 'Screenshot_1'
> (http://img248.imageshack.us/img248/7...enshot1mv2.png) shows,
> whenever I got this error message, Unlocker indicated that three files
> were locked by WLMail, namely tmp.edb, edb.log, and Mail.MSMessageStore.
>
> Now, upon further investigation, I realised that the file tmp.edb is
> created when WLMail is started, and is *normally* deleted as WLMail is
> closed. However, in *every* instance where this compacting error occurred,
> I found that the file tmp.edb was not deleted when WLMail was closed (as
> can be seen in 'Screenshot_2'
> (http://img266.imageshack.us/img266/9...enshot2yi6.png)).
>
> I used 'EndItAll' to close or kill all unnecessary programs and processes
> before opening WLMail, but this problem still occurred.
>
> I noticed also that the file tmp.edb is recreated during the database
> compaction process, but this tmp.edb file increases in size throughout the
> compaction process. So it would seem that this recreation of tmp.edb
> cannot occur whilst the old tmp.edb (128KB size) remains within the
> Message Store folder. Moreover, once the error message was cancelled, I
> found that those files are were no longer locked, so it seems that it is
> the initiation (beginning with the opt in question) of the compaction
> process itself that is locking those files.
>
> Now, I also found that even when no database compaction is due, as WLMail
> closes, the file tmp.edb was often not deleted as it should be, however it
> was not locked. The question is then, why was the file tmp.edb not always
> deleted as WLMail closed? If I opened WLMail and immediately closed it
> again without doing anything (such as sending/receiving messages, opening
> messages, composing messages etc.), I noticed that tmp.edb *was* deleted
> (thus database compaction succeeded). Interestingly, when the tmp.edb file
> was not deleted as WLMail closed, WLMail deleted it and then recreated it
> as WLMail was restarted. The file tmp.edb *was* also deleted after only
> downloading e-mails, and newsgroup headers, but when several (not sure
> how many it takes) newsgroup message bodies were downloaded and read,
> tmp.edb usually failed to be deleted as WLMail was closed. There may be
> other contributing factors, but as yet I have not narrowed them down.
>
> Thus, one workaround for this bug is to close WLMail immediately after
> opening it, whilst another may be to not use newsgroups, or not to
> download news bodies before closing WLMail. Doing this allows the database
> compaction to succeed because the tmp.edb invariably is deleted when
> WLMail is closed in this manner.
>
> Compacting the database did not rectify the problem.
> Doing a full uninstall of WLMail (deleted program files*, registry keys**,
> renamed Message Store folder***) before reinstalling did not rectify the
> problem (although initially it did appear to).
>
> *C:\Program Files\Windows Live\Mail
> **HKEY_CURRENT_USER\Software\Microsoft\Windows Live Mail
> ***C:\Documents and Settings\Peter\Local Settings\Application
> Data\Microsoft\Windows Live Mail.
>
> --
> Cheers,
> Peter
> (Windows Vista Home Premium with Windows Live Mail 12.0.1606)
> "There are more things in Heaven and earth, Horatio, than are dreamt of in
> your philosophy." - Shakespeare
> ---------------
>
> "Ron Sommer" <> wrote in message
> news:ujlfqj$...
>
>> Why are you saying that WLM not doing the compaction is a bug if the
>> compaction doesn't start on the first close after changing the number to
>> 1?
>>
>>
>> After the compaction, change value 'n' back to 100.
>> I don't think that you want a compaction on every close.
>> --
>> Ronald Sommer
>>
>> "Peter.R" <> wrote in message
>> news:eZBGlg#...

>
>> snipped>
>>> To manually compact the database, in WLMail, go to
>>> Tools->Options...->Advanced [tab]->Maintenance [button]->check the
>>> option "Compact the database on shutdown every 'n' runs" and change the
>>> value 'n' to '1'. Then exit WLMail and select "Yes" when asked to
>>> "Recover unused disk space". If the database compaction process fails
>>> to start, open WLMail again and immediately close it, as this is a
>>> workaround for that bug.
>>>

>> snipped

>

 
Reply With Quote
 
Peter.R
Guest
Posts: n/a

 
      02-12-2008
[inline...]

"Ron Sommer" <> wrote in message
news:#...

> Why did you say, "If you leave 'n' set as '100'"?


I was explaining to you why one would set 'n' to '1'. i.e. After a failed
compaction, don't wait for the next option to compact the database,
because if it is set to 100, you could be waiting many months (I very
rarely shut down WLMail myself). Thus, set it to '1' to manually force a
successful compaction.

I think it would be better if WLMail again offered to compact the database
at next shut-down if the compaction failed to start, whatever 'n' is set
to. Or maybe a non-sticky option to compact the database at next shut-down
of WLMail.

> 'n' was set to 1 to get the compaction to occur.
> If you leave 'n' at 1, won't WLM want to compact at every shutdown?


Yes, that is the idea, but obviously one would not leave it set to '1'
after a successful database compaction, unless for testing purposes or
they prefer it that way. I had credited readers with enough smarts to
realise that. Thus, after the successful 'manual' compaction, one would
either uncheck the compaction option altogether, or set the number back to
'100' or whatever number suits them. Personally, since I mostly use
newsgroups in WLMail, and using newsgroups is a contributing factor, I
leave the "Compact the database on shutdown every 'n' runs" *un-checked*
until I think it is time to do a manual database compaction.

--
Cheers,
Peter
(Windows Vista Home Premium with Windows Live Mail 12.0.1606)
"There are more things in Heaven and earth, Horatio, than are dreamt of in
your philosophy." - Shakespeare
---------------

 
Reply With Quote
 
Ron Sommer
Guest
Posts: n/a

 
      02-13-2008
Thanks for the explanation.
I agree with everything that you said.
--
Ronald Sommer

"Peter.R" <> wrote in message
news:...
> [inline...]
>
> "Ron Sommer" <> wrote in message
> news:#...
>
>> Why did you say, "If you leave 'n' set as '100'"?

>
> I was explaining to you why one would set 'n' to '1'. i.e. After a failed
> compaction, don't wait for the next option to compact the database,
> because if it is set to 100, you could be waiting many months (I very
> rarely shut down WLMail myself). Thus, set it to '1' to manually force a
> successful compaction.
>
> I think it would be better if WLMail again offered to compact the database
> at next shut-down if the compaction failed to start, whatever 'n' is set
> to. Or maybe a non-sticky option to compact the database at next shut-down
> of WLMail.
>
>> 'n' was set to 1 to get the compaction to occur.
>> If you leave 'n' at 1, won't WLM want to compact at every shutdown?

>
> Yes, that is the idea, but obviously one would not leave it set to '1'
> after a successful database compaction, unless for testing purposes or
> they prefer it that way. I had credited readers with enough smarts to
> realise that. Thus, after the successful 'manual' compaction, one would
> either uncheck the compaction option altogether, or set the number back to
> '100' or whatever number suits them. Personally, since I mostly use
> newsgroups in WLMail, and using newsgroups is a contributing factor, I
> leave the "Compact the database on shutdown every 'n' runs" *un-checked*
> until I think it is time to do a manual database compaction.
>
> --
> Cheers,
> Peter
> (Windows Vista Home Premium with Windows Live Mail 12.0.1606)
> "There are more things in Heaven and earth, Horatio, than are dreamt of in
> your philosophy." - Shakespeare
> ---------------


 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Opening message from WLMessenger pop-up fs_fan Windows Live Mail 1 01-09-2008 01:08 AM
Opening the wrong message bartleph Windows Vista Mail 3 11-19-2007 09:57 PM
Error Message When Opening IE7 stratcat43 Internet Explorer 3 07-22-2007 06:56 PM
Error when opening email : There was an error opening this message Moti Windows Live Mail 2 06-21-2007 09:53 PM
Error Message on Opening Fax GaryK51188 Windows Vista Printing / Faxing / Scanning 1 04-13-2007 10:15 PM



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59