I use different icons for the various shortcuts to the different mail accounts. I, too, have issues restoring Pegasus Mail from the Notification Area so just hover over the flapping wings until the name appears and then click the Taskbar entry. The different icons help me recognise which account is which.

Well, in the last few days I've finally started using PM V4.70 in earnest on a recently-built Win7 (32-bit Professional) machine after migrating all my mail folders and PM config stuff off the WinXP machine on which I'd used an earlier version (V4.21c I think) reliably for many (approaching ten) years.  Unfortunately I'm finding that V4.70 on the Win7 machine is decidely unreliable, in the following ways:

Firstly, PM sometimes crashes when I try to do standard things such as reply to or send an email; Windows reports the crash and the following is the report that was generated by Windows a few minutes ago at the time of the most recent crash:

 Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    WINPM-32.EXE
  Application Version:    4.7.0.1
  Application Timestamp:    530f0f0f
  Fault Module Name:    WINPM-32.EXE
  Fault Module Version:    4.7.0.1
  Fault Module Timestamp:    530f0f0f
  Exception Code:    c0000005
  Exception Offset:    003d9a49
  OS Version:    6.1.7601.2.1.0.256.48
  Locale ID:    2057
  Additional Information 1:    0a9e
  Additional Information 2:    0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:    0a9e
  Additional Information 4:    0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt
 

I haven't observed any clear pattern for the cause of these crashes - they seem to happen only sometimes when I try to do something absolutely standard like sending a reply to a received email.  As far as I've been able to tell, there's nothing in the content of a received email that I'm trying to open or to reply to that might be causing the crash - I can restart PM after the crash and then successfully achieve what I was trying to do before the crash happened.  It's extremely annoying, not least because my previous experiences of PM over almost 20 years have been almost entirely positive.

The second issue I'm having is associated with the 'Change User' function that I'm invoking via a button in a custom toolbar - see my postings of a few weeks ago this.  When I invoke the 'Change User' function using the toolbar button and enter a different username into the dialogue box, most of the time PM changes to the desired user successfully.  However, occasionally when I enter the username and then hit the 'Enter' key PM disappears and shuts down completely, with no dialogue or error messages whatsoever.  When I then restart PM from the desktop shortcut it comes back up minimised, in the user account to which I was trying to change.

I realise and accept that the 'Change User' function isn't now the preferred way of accessing multiple mail user accounts, but it's a function that I've used happily and entirely reliably over many years so I'd like to continue using it as long as it behaves reliably, which sadly it's currently not.

Does anyone have any thoughts about the causes of the issues I'm having with V4.70, most especially the first one described above?  It really is annoying and frustrating to have a program as good as PM misbehave and be unreliable in this way...

Thanks in advance,

-- 

Martin

[quote user="Martin Davies"]Firstly, PM sometimes crashes when I try to do standard things such as reply to or send an email; Windows reports the crash and the following is the report that was generated by Windows a few minutes ago at the time of the most recent crash:[/quote]

The kind of report MS creates is useless to us. Please read the following post from the top of this forum for dealing with crashes.

[quote user="Martin Davies"]The second issue I'm having is associated with the 'Change User' function that I'm invoking via a button in a custom toolbar - see my postings of a few weeks ago this.  When I invoke the 'Change User' function using the toolbar button and enter a different username into the dialogue box, most of the time PM changes to the desired user successfully.  However, occasionally when I enter the username and then hit the 'Enter' key PM disappears and shuts down completely, with no dialogue or error messages whatsoever.[/quote]

This is one of the reasons for officially abandoning this functionality. Things like this happened to other users in previous versions already.

[quote user="Martin Davies"]The second issue I'm having is associated with the 'Change User' function that I'm invoking via a button in a custom toolbar ...[/quote]

We also painfully miss the opportunity to change a user quickly without shutting-down PM and restarting it with option "winpm-32.exe -i user name ". We are using Pmail in connection with Mercury (properly licenced) also since many years in our company. Here we have often to check the mail account of other colleagues in case they are on a business trip or sick. In former versions of Pmail this was simply by using the "changed user" functionality. But since a few versions this functionality (which was always working fine without fails) has been taken away. It's a pity but no really news.

Joerg

Hello Michael, thank you for your response to my posting and your reference to the posting about how to deal with crashes.

I have downloaded and installed Minidump and as far as I can tell it is enabled as an extension - it's included in the list of extensions and when I use the 'Extensions Manager' function I can highlight it and click on the 'Use' button - but on the recent occasions when V4.70 has crashed there has been no action whatsoever from Minidump.  The only dialogue I've seen when the crash has occurred is the standard Windows 'Appcrash' report as I included in my earlier posting.

I've looked in my Windows Temp folder, which is where the Minidump ReadMe states a crash report should be written, and there's nothing in there relating to the crashes.

The most recent crash occurred a short time ago when I tried to send an email; when I restarted PM after the crash it came up with the usual 'locked folder' message for the username in question and then offered the incomplete auto-saved version of the draft message that I'd composed which I was then able to complete and send successfully.

I'll welcome any further suggestions you might have about how to capture the crash details, or if I need to do something else to get Minidump to operate as described in the ReadMe.

With regard to the 'Change User' function, with the system function 10249 invoked via the custom toolbar button, not always behaving as it should, I can live with PM very occassionally shutting down when I try to change user - most of the time the function works fine and on the few occasions when it does misbehave it's no worse than having to close and then restart PM in order to change user.  The problem with the crashes is the one I'd really like to get sorted out.

Regards

-- 

Martin

Hi, Martin

One thing to check is the installation path. Make sure that Pegasus Mail is installed in a subfolder off your C:\ drive and not in a folder off C:\Program Files. Ideally, install it to C:\PMail.

Regarding the 'change user' issue, you can have more than instance of Pegasus Mail open at any time and thus have access to all your mail accounts at once.

To do this create several shortcuts to wimpm-32.exe. Right-click the first shortcut and at the end of the path in the Target field type -i username -ms

C:\PMail\winpm-32.exe -i fred -ms

The -i switch allows you specify the logon name of the Pegasus Mail account. The -ms switch allows you to have several Pegasus Mail sessions open so long as the -ms switch is defined in each shortcut.

I have three accounts open on my Win7 Pro 64bit machine all the time without issue.

I'm with Greenman.  In fact, I created a shortcut to a batch file that opens two instances of Pegasus Mail, one for my personal mailbox and one for the office catch-all mailbox.  I also usually have a third instance running from a USB stick.

Joerg, when I need to check the mailbox of a vacationing user I use the "Add mailbox to list" function (Joerg and I have a similar setup of Mercury and Pegasus).

[quote user="Martin Davies"]I'll welcome any further suggestions you might have about how to capture the crash details, or if I need to do something else to get Minidump to operate as described in the ReadMe.[/quote]

In this case you will need to use MiniDump's "stand-alone" mode because the extension itself is affected by the crash as well. The easiest way for doing so is using the Pegasus Mail Debugger entry from the Start menu group created by the installer (if you didn't deselect it, otherwise just repeat the installation with this option enabled): It'll start Pegasus Mail automatically with the commandline used previously by you. If you want to start Pegasus Mail repeatedly via debugger you may even create a shortcut like described in MiniDump's ReadMe file (in its Debugger section).

[quote user="bfluet"]Joerg, when I need to check the mailbox of a vacationing user I use the "Add mailbox to list" function (Joerg and I have a similar setup of Mercury and Pegasus).[/quote]

Hi Brian,

I cannot permanently add the mailbox of a sick user to my mailbox because those mailbox may also being checked from time to time by other colleagues. And as long as the mailbox is occupied by me, the other users would get an error message that the mailbox is in use or not closed properly. Then they would anoying me the whole day: please close the mailbox :-)

We also do not prefer the opportunity for checking another mailbox by starting another instance of Pmail, where I have to create shortcuts for each of our 15 users to each of our 15 user desktops.

Anybody in our company needs only a quick opportunity to look inside another mailbox in case that user is out of office. After checking it will immediately being closed again. The "Change User" opportunity of former versions was perfect for us [:'(]

I don't leave an added mailbox connected.  I add it to the list, do what I need to do, then disconnect it.  I might do this several times a day for a vacationing user.

FWIW, I didn't like the change user function because I didn't like the obvious indication to users that they could access another users mailbox.  In fact, I remember working on figuring out the right combination of permissions to allow Pegasus Mail to deliver locally while preventing any user (except admins) from accessing another users mailbox (this was before Mercury).  The add mailbox function doesn't change this concern but it is so well hidden that I doubt many of my users know it exists.

[quote user="Greenman"]

Hi, Martin

One thing to check is the installation path. Make sure that Pegasus Mail is installed in a subfolder off your C:\ drive and not in a folder off C:\Program Files. Ideally, install it to C:\PMail.

[/quote]

Hello Greenman, thanks for the reply.  I'd realised a liitle while before I saw your posting that I had installed PM V4.70 in C:\Program Files\Pmail (which is where PM was always installed when I used it on Win95, Win98 and WinXP systems), so when I saw your posting I had just finished de-installing it and then re-installing it in C:\Pmail as recommended!  It took me a liitle while to get the re-installed version accessing all my mailboxes, which are on the E: drive, but I eventually succeeded and the program is now installed where it should be and accessing all my mailboxes successfully.

[quote user="Greenman"]

Regarding the 'change user' issue, you can have more than instance of Pegasus Mail open at any time and thus have access to all your mail accounts at once.

To do this create several shortcuts to wimpm-32.exe. Right-click the first shortcut and at the end of the path in the Target field type -i username -ms

C:\PMail\winpm-32.exe -i fred -ms

The -i switch allows you specify the logon name of the Pegasus Mail account. The -ms switch allows you to have several Pegasus Mail sessions open so long as the -ms switch is defined in each shortcut.

I have three accounts open on my Win7 Pro 64bit machine all the time without issue.

[/quote]

I do note and acknowledge that the now-recommended way of accessing multiple mailboxes is to run multiple PM sessions concurrently; however I have almost no need to see more than one mailbox at a time which is why the ability to switch user as and when I want to was so useful.  Although I haven't done much user-switching since I re-installed PM earlier today, the 'Change User' function invoked by the button in my custom toolbar has seemed to work OK when I've used it - time will tell whether it continues to do so!

Thanks again for the assistance and suggestions,

-- 

Martin

Thanks for the further guidance, Michael.

As I've reported in another posting I've now re-installed PM V4.70 in C:\Pmail - it was previously in C:\Program Files\Pmail.  I haven't yet re-installed MiniDump but will do so later today as per your suggestions and will see what happens if and when PM crashes again - it did crash when I opened a message immediately after the re-install but I haven't done much else with PM since then.

I'll let you know what MiniDump does after I've re-installed it.

Regards

-- 

Martin

[quote user="idw"]

In this case you will need to use MiniDump's "stand-alone" mode because the extension itself is affected by the crash as well. The easiest way for doing so is using the Pegasus Mail Debugger entry from the Start menu group created by the installer (if you didn't deselect it, otherwise just repeat the installation with this option enabled): It'll start Pegasus Mail automatically with the commandline used previously by you. If you want to start Pegasus Mail repeatedly via debugger you may even create a shortcut like described in MiniDump's ReadMe file (in its Debugger section).

[/quote]

Hello Michael, just to let you know that I installed MiniDump again and had the PMDebugger running in standalone mode - I started PM first followed by starting PMDebugger from the Start menu, the Debugger reported that it had successfully attached itself to the sole running instance of PM.

A short time ago (at approx 1202z today, Sat 6th Dec) I composed an email and when I tried to send it PM crashed and the Debugger generated a dump file; this has now been sent as a CAB file to the beta-reports email address.  I received an auto-reply which I then tried to forward to another of my usernames (admin@.....), this caused another crash but at that point the Debugger wasn't running so another dump file didn't get generated.

I hope the dump file is useful; it really would be nice to know why V4.70 is proving to be so crash-prone on my Win7 system and to resolve whatever the cause is.

Regards

-- 

Martin

I suspect that eventually you will need to revisit your transfer process, as this is a more likely reason for the frequent crashes, rather than deficiencies in Pmail or the os.

[quote user="caisson"]I suspect that eventually you will need to revisit your transfer process, as this is a more likely reason for the frequent crashes, rather than deficiencies in Pmail or the os.
[/quote]

Hello James, thanks for the input.

Just for completeness and the avoidance of doubt, I'm using PM in standalone mode for accessing several different email accounts at my Internet hostname - the user accounts are all in the form <username>@<myhostname>.demon.co.uk.

On my old WinXP machine I had the PM program installed in C:\Program Files\PMAIL; all the user mailbox folders were on the E: drive in E:\PMAIL\MAIL\<username>.  I always keep my 'working files', be they for PM, Word, Excel or whatever, on a separate partition/logical drive so that if ever I lose the C: drive, all my data will hopefully still be intact.  Also, the entire E: drive is backed-up daily to at least two separate destinations and in two formats.

When I did the migration of my PM repository, I copied the entire E:\PMAIL folder with all its sub-folders from the old WinXP machine onto the newly-created E: drive on the WIn7 machine.  I then installed PM onto the Win7 machine - although it was initially in C:\Program Files\PMAIL it's now in C:\PMAIL as recommended - and I then made sure that PMAIL.CFG was correctly pointing to the E: drive, which it is.  PM V4.70 doesn't have any problems whatsoever accessing all the mailbox folders and their contents on the E: drive for my several different usernames so unless there's something extra that needs to be done as part of the migration that I'm completely unaware of, I don't believe there's been a problem with the migration.

I've also just been through the entire E:\PMAIL folder and all its sub-folders and made sure that the permissions allow everyone full control; despite doing this PM crashed again a short time ago when I tried to reply to a new mail message in one of the users' inboxes - very frustrating, although for much of today I have been able to compose and send both new messages and replies to incoming messages so PM works most of the time.  I haven't yet submitted the report for this most recent crash.

I'll welcome any further suggestions you might have about the migration, especially if you think there's something else I should have done to aid the migration from the old WinXP machine to the newly-built and pretty much 'bog-standard' Win7 machine - I don't believe there's anything odd or unusual on the machine that PM might take a dislike to.

Regards

-- 

Martin

The problem might be with the mailboxes, as they contain original configuration files, pmail.ini particularly, that include settings from the original installation.

Usually when the two installations have differing paths it is best to be conservative.

Such an approach would have been to carry out a clean install of the program, including recreating your user base, then selectively transferring files from the old mailboxes to the new, leaving behind the configuration files.

Martin,

As caisson stated, the only time you can use the entire contents of a mailbox is when the paths to both the program files and the mailbox directories are identical.  There are files other than pmail.ini that contain paths so just correcting it is not enough.  There is a white paper that lists the files that are safe to copy from an old mailbox directory to a new one.  It was created for exactly your scenario.  Find it here:

http://community.pmail.com/files/folders/whitepapers/entry41852.aspx

Note: This white paper was created prior to Pegasus Mail v4.70 which introduced a different dictionary system so be aware that the file USRDICT3.PMD should not be copied.  It is USRDICT5.PMD in v4.70. 

FYI:  The file protection of the \Program Files directory that is built into Win7 is what prevents Pegasus Mail from functioning properly if installed anywhere in a \Program Files directory like we were able to do in OSes up through XP.

My suggestion is to move all files out of the existing mailbox directories then start Pegasus Mail.  It will start up needing to be configured.  Reconfigure it then move files back in to the mailbox directories as per the above guide.  This process is a pain if you have multiple users or a large number of identities but it is the only way to insure that none of the old configuration files affect the new install.  The old pmail.ini files can serve as a reference resource during reconfiguration.

[quote user="bfluet"]

Martin,

As caisson stated, the only time you can use the entire contents of a mailbox is when the paths to both the program files and the mailbox directories are identical.  There are files other than pmail.ini that contain paths so just correcting it is not enough.  There is a white paper that lists the files that are safe to copy from an old mailbox directory to a new one.  It was created for exactly your scenario.  Find it here:

http://community.pmail.com/files/folders/whitepapers/entry41852.aspx

Note: This white paper was created prior to Pegasus Mail v4.70 which introduced a different dictionary system so be aware that the file USRDICT3.PMD should not be copied.  It is USRDICT5.PMD in v4.70. 

FYI:  The file protection of the \Program Files directory that is built into Win7 is what prevents Pegasus Mail from functioning properly if installed anywhere in a \Program Files directory like we were able to do in OSes up through XP.

My suggestion is to move all files out of the existing mailbox directories then start Pegasus Mail.  It will start up needing to be configured.  Reconfigure it then move files back in to the mailbox directories as per the above guide.  This process is a pain if you have multiple users or a large number of identities but it is the only way to insure that none of the old configuration files affect the new install.  The old pmail.ini files can serve as a reference resource during reconfiguration.

[/quote]

Thanks for all the information Brian, and also thanks to Caisson for the earlier suggestions about the migration being the cause of my unreliability problems.

I've had a look at the white paper and I think I'm clear about what to do next; my proposed approach is:

1.  Firstly (after shutting down PM!), I'll mirror my entire E: drive, which includes the E:\PMAIL\MAIL folder and hence all the user-specific sub-folders and their contents, onto both of my NAS's so that I've got two fully up-to-date copies of everything relating to PM (apart from the executables etc which are now in C:\PMAIL).  The mirroring of the PC's E: drive to the NAS's is part of my daily backup routine anyway, and was how I copied everything from the old WinXP machine's E: drive onto the Win7 machine's E: drive.

2.  Once I've copied everything from the E:\PMAIL folder onto the NAS's, I'll delete everything in one of the user folders under E:\PMAIL\MAIL on the Win7 PC, and will then restart PM using that username.  As you indicate, I'll have to reconfigure everything for that user but hopefully this shouldn't be too onerous - I use no identities other than the default one so it should just be a case of re-entering the SMTP and POP3 details, Internet and reply-to email addresses, personal name, plus setting any options that I've used (if I can remember them all!).

3.  Hopefully once I've done this then that user account should work, although I assume it will be empty - there presumably won't be any folders showing under 'My mailbox' and there won't be anything in the 'New mail folder'.

4.  Once the selected user account is working then I'll delete the following files from that user folder under E:\PMAIL\MAIL on the NAS:  PMAIL.INI;  STATE.PMJ;  HIERARCH.PM;  FOLSTATE.PM;  and *.PND.  These are the files identified in the white paper as the ones that shouldn't be over-written in a new PM installation so I don't want these being copied back from the NAS to the PC.

5.  Having deleted the above-mentioned files from the selected user folder on the NAS, I'll copy everything else from that user folder on the NAS back into the corresponding user folder under E:\PMAIL\MAIL on the PC.  Having done this, all the original folders and their contents will re-appear under 'My mailbox', together with anything that was previously in the 'New mail folder', and everything will work reliably won't it...??!!  [:)]

Assuming the above process works successfully and there are no more PM crashes when I use that username, I'll repeat the process for the rest of my usernames - fortunately there's currently only five or six that I use regularly so the process shouldn't take too long.

How does that sound to you?  If you think I've missed anything then please let me know!  I won't embark on the process until tomorrow (Tuesday) now but in the meantime I'll welcome your comments on the viability and robustness of the proposed process.

Kind regards and thanks again to both for your assistance,

--

Martin

You have the right idea.  Only thing I would do differently is to copy files back in stages, say all .cnm files, then test; all .pmm/pmi file pairs, test; addressbooks & dlists, test... You get the idea.  This way if it breaks you know exactly what step caused the problem and can undo it until you figure it out why.  Files that you can't identify or whose content can easily be created in the new install should not be brought back.  This will minimize the chance of ghosts from days past haunting the new install.

[quote user="Martin Davies"]I hope the dump file is useful; it really would be nice to know why V4.70 is proving to be so crash-prone on my Win7 system and to resolve whatever the cause is.[/quote]

All the crash reports you submitted point to a routine doing address parsing (actually called "resolve_alias()"). As I've never seen anything like this I need to ask David Harris about what could be the reason for these crashes. I'll send you a personal message containing the affected adresses so you can tell whether they are from an address book or not.