Community Discussions and Support
problem after windows 10 April Update, version 1803

Upgrading the server is what worked here. The old server was running XP (yes, I know...) and AIUI 1803 wouldn't allow the client PC to collect mail via the server (because SMBv1). So, assigned a newer server to host the mailboxes etc, and Pegasus has been fine since, despite upgrading to 1903.

Thanks for the assistance!

<p>Upgrading the server is what worked here. The old server was running XP (yes, I know...) and AIUI 1803 wouldn't allow the client PC to collect mail via the server (because SMBv1). So, assigned a newer server to host the mailboxes etc, and Pegasus has been fine since, despite upgrading to 1903. </p><p>Thanks for the assistance!</p>

Hello, we report an error that occurred after the update windows 10 to windows 10 April update 1803.

An error occurs  when we are sending and receiving mail:
 
A network error occurred during connection to the host

16:32:38.961: --- 3 May 2018, 16:32:38.961 ---
16:32:38.961: Connect to 'pop3.xxxxxxxxxxxxxx.it', timeout 60 seconds.
16:32:38.961: 3: Socket failed, 10022 (no error description available)
 
------------------------------------------------------------------------------------------------- 
 
This information is shown when i open pegasus in my pc without any local installation of pegasus: 
Pegasus Mail for Microsoft Windows
WinPMail version: Version 4.72.572, Feb 19 2016, build ID 572
Language resources: Standard UK English resource set
Extension Manager version: 1.14
Operating mode: Standalone
User name and ID: xxxxxxx, 0
Windows version: 6.2
Windows flag word: 0
WINPMAIL.EXE directory: F:\PMAIL
Home mailbox location: F:\PMAIL\MAIL\xxxxxxxxx
New mailbox location: F:\PMAIL\MAIL\xxxxxxxxx
TMP environment variable: C:\Users\xxx\AppData\Local\Temp
TEMP environment variable: C:\Users\xxxxx\AppData\Local\Temp
LAN-based SMTP support: N, N, N
NetWare MHS support: N, N, N
Built-in TCP/IP support: Enabled
  - WINSOCK version: WinSock 2.0
  - WINSOCK path: WSOCK32.DLL
Commandline: 
Active -Z options: 32768
PMR variable: (None)
PML variable: (None)
MAI variable: (None)
NB variable: (None)
Autofiltering folders: 0 (0 active, 0 inactive)
Last new mail count: 0
Message size soft limit: 0 bytes
Message size hard limit: 0 bytes
Attachment size soft limit: 0 bytes
Attachment size hard limit: 0 bytes
--------------------------------------------------------------------- 
 
Before update everything worked right.

We have pegasus mail intalled on a windows server and users logged in other pc  (without any local installation of pegasus) access to pegasus mail with a shortcut on their desktop.
The shortcut point to the executable on a network folder.
 
we have tryed with another pc with a local installation of pegasus 4.71 and the error does not occur. 
we have to do some more tests with this solution (with 4.72 version) even if we prefer do not install pegasus locally on all PCs.
 
any idea to fix the problem without install pegasus on all our pcs?
 
Thank you
 
Elena 
<div><span style="font-size: 10pt;">Hello, we report an error that occurred after the update</span><span style="font-size: 10pt;"> windows 10 to windows 10 April update 1803.</span></div><div> </div><div><span style="font-size: 10pt;">An error</span> occurs<span style="font-size: 10pt;">  when we are sending and receiving mail:</span></div><div> </div><div>A network error occurred during connection to the host</div><div> </div><div>16:32:38.961: --- 3 May 2018, 16:32:38.961 ---</div><div>16:32:38.961: Connect to 'pop3.xxxxxxxxxxxxxx.it', timeout 60 seconds.</div><div>16:32:38.961: 3: Socket failed, 10022 (no error description available)</div><div> </div><div>------------------------------------------------------------------------------------------------- </div><div> </div><div><span style="font-size: 10pt;">This information is shown when i open pegasus in my pc without any local installation of pegasus:</span><span style="font-size: 10pt;"> </span></div><div>Pegasus Mail for Microsoft Windows</div><div>WinPMail version: Version 4.72.572, Feb 19 2016, build ID 572</div><div>Language resources: Standard UK English resource set</div><div>Extension Manager version: 1.14</div><div>Operating mode: Standalone</div><div>User name and ID: xxxxxxx, 0</div><div>Windows version: 6.2</div><div>Windows flag word: 0</div><div>WINPMAIL.EXE directory: F:\PMAIL</div><div>Home mailbox location: F:\PMAIL\MAIL\xxxxxxxxx</div><div>New mailbox location: F:\PMAIL\MAIL\xxxxxxxxx</div><div>TMP environment variable: C:\Users\xxx\AppData\Local\Temp</div><div>TEMP environment variable: C:\Users\xxxxx\AppData\Local\Temp</div><div>LAN-based SMTP support: N, N, N</div><div>NetWare MHS support: N, N, N</div><div>Built-in TCP/IP support: Enabled</div><div>  - WINSOCK version: WinSock 2.0</div><div>  - WINSOCK path: WSOCK32.DLL</div><div>Commandline: </div><div>Active -Z options: 32768</div><div>PMR variable: (None)</div><div>PML variable: (None)</div><div>MAI variable: (None)</div><div>NB variable: (None)</div><div>Autofiltering folders: 0 (0 active, 0 inactive)</div><div>Last new mail count: 0</div><div>Message size soft limit: 0 bytes</div><div>Message size hard limit: 0 bytes</div><div>Attachment size soft limit: 0 bytes</div><div>Attachment size hard limit: 0 bytes</div><div>--------------------------------------------------------------------- </div><div> </div><div><div style="font-size: 13.3333px;">Before update everything worked right.</div><div style="font-size: 13.3333px;"> </div><div style="font-size: 13.3333px;">We have pegasus mail intalled on a windows server and users logged in other pc  (without any local installation of pegasus) access to pegasus mail with a shortcut on their desktop.</div><div style="font-size: 13.3333px;">The <span style="font-size: 13.3333px;">shortcut</span><span style="font-size: 13.3333px;"> </span><span style="font-size: 10pt;">point to the executable on a network folder.</span></div><div style="font-size: 13.3333px;"> </div><div style=""><span style="font-size: 13.3333px;">we have tryed with another pc with a local installation of pegasus 4.71 and the error does not occur. </span> <span style="font-size: 13.3333px;">we have to do some more tests with this solution (with 4.72 version) even if we prefer do not install pegasus locally on all PCs.</span></div><div style="font-size: 13.3333px;"> </div><div style="font-size: 13.3333px;">any idea to fix the problem without install pegasus on all our pcs?</div></div><div style="font-size: 13.3333px;"> </div><div style="font-size: 13.3333px;"><span style="font-family: arial, sans-serif; font-size: 13px; white-space: nowrap;">Thank you</span></div><div style="font-size: 13.3333px;"> </div><div style="font-size: 13.3333px;">Elena </div>

That Socket 10022 error can be an indication that the executable is being blocked.  I sure hope MS hasn't done something to block executables on servers.  A quick web search specific to 1803 didn't find any hits but a more general one found this socket error  several came up associated with Win7 in 2013 . 

I don't have an answer specific to 1803 but suggest you confirm that users have Read permissions to F: and Read and Execute to \PMAIL.  You might also disconnect F: and then remap it.  I would add a hard boot in between.

Also, an issue with Windows Firewall comes to mind.  Confirm winpm-32.exe is an allowed app. 

<p>That Socket 10022 error can be an indication that the executable is being blocked.  I sure hope MS hasn't done something to block executables on servers.  A quick web search specific to 1803 didn't find any hits but a more general one found this socket error  several came up associated with Win7 in 2013 .  </p><p>I don't have an answer specific to 1803 but suggest you confirm that users have Read permissions to F: and Read and Execute to \PMAIL.  You might also disconnect F: and then remap it.  I would add a hard boot in between.</p><p>Also, an issue with Windows Firewall comes to mind.  Confirm winpm-32.exe is an allowed app.  </p>

hello,

with a local installation of pegasus 4.72 pointing to the server mail folder it works.

but the direct launch of the executable from the network folder still provides the Socket 10022 error


i confirm that users have Read permissions to F: and Read and Execute to \PMAIL.

i try to disable antivirus firewall and windows defender firewall 


maybe MS changes some library or something else is blocking the network functions of the program.

we will continue to look for a solution

 

 Elena 



 

<p style=""><span style="font-size: 13.3333px;">hello,</span></p><p style=""><span style="font-size: 13.3333px;">with a local installation of pegasus 4.72 pointing to the server mail folder it works.</span></p><p style=""><span style="font-size: 13.3333px;">but the direct launch of the executable from the network folder still provides the Socket 10022 error</span></p><p style=""><span style="font-size: 13.3333px;"> </span></p><p style=""><span style="font-size: 13.3333px;">i confirm that users have Read permissions to F: and Read and Execute to \PMAIL.</span></p><p style=""><span style="font-size: 13.3333px;">i try to disable antivirus firewall and windows defender firewall </span></p><p style=""><span style="font-size: 13.3333px;"> </span></p><p style=""><span style="font-size: 13.3333px;">maybe MS changes some library or something else is blocking the network functions of the program.</span></p><p style="">we will continue to look for a solution</p><p style=""> </p><p style=""> <span style="font-size: 10pt;">Elena</span><span style="font-size: 10pt;"> </span></p><p style=""> </p><p style=""><span style="font-size: 13.3333px;"> </span></p><p style=""><span style="font-size: 13.3333px;"> </span></p>

Hi,

 

I've had the same problem with a server installation, and agree this appears to be caused by the 1803 update. Only one PC on my network updated to 1803 and couldn't download email for any account. I tried allowing Winpm-32.exe through the firewall, but this made no difference. Other PCs that weren't updated to 1803 could open the same user account and all worked as normal.

 

For now, we rolled back the 1803 update, and all works as before. We've disabled Windows updates until we find out why this happened.

<p>Hi,</p><p> </p><p><span style="font-size: 10pt;">I've had the same problem with a server installation, and agree this appears to be caused by the 1803 update. Only one PC on my network updated to 1803 and couldn't download email for any account. I tried allowing Winpm-32.exe through the firewall, but this made no difference. Other PCs that weren't updated to 1803 could open the same user account and all worked as normal.</span></p><p> </p><p>For now, we rolled back the 1803 update, and all works as before. We've disabled Windows updates until we find out why this happened.</p>

Just to let you know that this problem has been brought to my attention.  If, as it appears, MS is preventing executables to be run from server volumes, then I doubt there is much I can do about it, but should a viable solution present itself, I'll happily work on implementing it.

Cheers!

-- David --

<p>Just to let you know that this problem has been brought to my attention.  If, as it appears, MS is preventing executables to be run from server volumes, then I doubt there is much I can do about it, but should a viable solution present itself, I'll happily work on implementing it. Cheers! -- David -- </p>

Hi guys,

Could you more detail your problem please? Is starting Pmail from a server share the problem, or could you start Pmail but sending mails returns the error? "Elems" wrote that sending mails is the problem, while "Ferret04" wrote that accessing the user account is the problem. But maybe I've missunderstood it.

Further, is your Pmail installation working together with a Mercury Mail Server or is it a stand-alone Pmail installation where Pmail is sending the mails to the internet itself?

At the moment we are using a Pmail multi-user server installation, where Pmail executables reside at a Windows Server 2016 (which is using the Windows10 engine). But Windows Server systems are still on version 1607. Also our Mercury Mail Server is running at this server. Client computers are still on Windows 7 but will be upgraded to W10 soon (at the latest when MS ceases the support for W7). At the moment all works fine here, but I would like being prepared.

Thanks

Joerg

<p>Hi guys,</p><p>Could you more detail your problem please? Is starting Pmail from a server share the problem, or could you start Pmail but sending mails returns the error? "Elems" wrote that sending mails is the problem, while "Ferret04" wrote that accessing the user account is the problem. But maybe I've missunderstood it. </p><p>Further, is your Pmail installation working together with a Mercury Mail Server or is it a stand-alone Pmail installation where Pmail is sending the mails to the internet itself?</p><p>At the moment we are using a Pmail multi-user server installation, where Pmail executables reside at a Windows Server 2016 (which is using the Windows10 engine). But Windows Server systems are still on version 1607. Also our Mercury Mail Server is running at this server. Client computers are still on Windows 7 but will be upgraded to W10 soon (at the latest when MS ceases the support for W7). At the moment all works fine here, but I would like being prepared.</p><p>Thanks</p><p>Joerg </p>

My Windows 10 64-bit PC crashed with blue screen. It offered that the only solution was a rebuild of my system. As I has no other solution I agreed. The rebuilt system ran long enough for me to run some diagnostics such as MemCheck before crashing again.  This time I was given the option to use a recovery point restore, which I pointed at the restore prior to the May upgrade.  After I got through the restore, everything is fine and I have had no further problems.  I am now trying to find out how to stop further Microsoft upgrades until they fix their problem.

Martin

<p>My Windows 10 64-bit PC crashed with blue screen. It offered that the only solution was a rebuild of my system. As I has no other solution I agreed. The rebuilt system ran long enough for me to run some diagnostics such as MemCheck before crashing again.  This time I was given the option to use a recovery point restore, which I pointed at the restore prior to the May upgrade.  After I got through the restore, everything is fine and I have had no further problems.  I am now trying to find out how to stop further Microsoft upgrades until they fix their problem.</p><p>Martin </p>

This looks like some more info on the problem, with some workarounds - http://woshub.com/windows-10-1803-cant-run-exe-files-shared-folders/

 

Their summary:

It can be concluded that Windows 10 update 1803 for security reasons does not allow you to open network connections in programs running from shared folders that are accessible only using the SMBv1 protocol. As network folders, you need to use devices that support SMBv2 or SMBv3. 

 

Meanwhile, the commentors of the above story blame Windows Defender.  This site mentions some changes to it in 1803 - https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard.  Specifically under Attack Surface Reduction Rules is listed five new rules, one of which is:

  • Block executable files from running unless they meet a prevalence, age, or trusted list criteria

 

<p>This looks like some more info on the problem, with some workarounds - http://woshub.com/windows-10-1803-cant-run-exe-files-shared-folders/</p><p> </p><p>Their summary:</p><p><span style="color: rgb(49, 49, 49); font-family: Tahoma, Geneva, sans-serif; font-size: 14px;">It can be concluded that Windows 10 update 1803 for security reasons does not allow you to open network connections in programs running from shared folders that are accessible only using the SMBv1 protocol. As network folders, you need to use devices that support SMBv2 or SMBv3.</span> </p><p> </p><p>Meanwhile, the commentors of the above story blame Windows Defender.  This site mentions some changes to it in 1803 - https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard.  Specifically under Attack Surface Reduction Rules is listed five new rules, one of which is:</p><ul style="margin: 16px 0px 16px 38px; padding: 0px; font-family: segoe-ui_normal, 'Segoe UI', Segoe, 'Segoe WP', 'Helvetica Neue', Helvetica, sans-serif; font-size: 16px;"><li style="list-style: disc outside none;">Block executable files from running unless they meet a prevalence, age, or trusted list criteria</li></ul><p> </p>

Hi Guys,

Although we've got some Windows 10 machines running since a couple of weeks, now our first user machine has been upgraded from W7 to W10 (1803). And despite of the obove said in this thread Pegasus is running fine so far, especially since every user is starting its Pmail session from a server share. Pmail is not locally installed. I put only a link to "\\serverpath\winpm-32.exe -i user" at the user's desktop.

Only one thing is a little bit annoying: When starting Pmail it needs a quite long time for folder localization, scanning of folder hierachy etc.. Defender exclusion from scanning of the affected user mailbox doesn't show effect. Has anybody an idea to shorten the startup time of Pmail?

<p>Hi Guys,</p><p>Although we've got some Windows 10 machines running since a couple of weeks, now our first user machine has been upgraded from W7 to W10 (1803). And despite of the obove said in this thread Pegasus is running fine so far, especially since every user is starting its Pmail session from a server share. Pmail is not locally installed. I put only a link to "\\serverpath\winpm-32.exe -i user" at the user's desktop. </p><p>Only one thing is a little bit annoying: When starting Pmail it needs a quite long time for folder localization, scanning of folder hierachy etc.. Defender exclusion from scanning of the affected user mailbox doesn't show effect. Has anybody an idea to shorten the startup time of Pmail? </p>

How long in time? 

I don't have any Win10 machines so I don't have any advice but I'm curious to compare what you are experiencing to my startup of around 10 seconds for just over 1000 folders and 80-100 messages in the NMF (usually around 20 unread).

 

<p>How long in time?  </p><p>I don't have any Win10 machines so I don't have any advice but I'm curious to compare what you are experiencing to my startup of around 10 seconds for just over 1000 folders and 80-100 messages in the NMF (usually around 20 unread).</p><p> </p>

Hi Brian,

Under W7 the startup with more than 1000 folders takes round about 3-5 seconds. Under W10 it takes about 15-25 seconds. Sounds not soo much, but when sitting in front of the machine - tick tack, tick tack [;)]

<p>Hi Brian,</p><p>Under W7 the startup with more than 1000 folders takes round about 3-5 seconds. Under W10 it takes about 15-25 seconds. Sounds not soo much, but when sitting in front of the machine - tick tack, tick tack [;)] </p>

15-25 does sound like a long time.  It it every startup?

On my Win7 the 10ish second start only applies to the first start of the morning and that time is mostly spent processing the folders.  If I restart during the day its 3-5 seconds.

<p>15-25 does sound like a long time.  It it every startup?</p><p>On my Win7 the 10ish second start only applies to the first start of the morning and that time is mostly spent processing the folders.  If I restart during the day its 3-5 seconds. </p>

Just checked with another W10 machine. The first start, until the inbox is showing all messages, lasts 21 seconds. The seconds start takes 15 seconds.

Just checked with another W10 machine. The first start, until the inbox is showing all messages, lasts 21 seconds. The seconds start takes 15 seconds.

I wish I could help but I don't have a clue.  Thinking out loud...

- Default printer issue?

- Test with the -A commandline option added (I don't hold much hope that it will make any difference) 

- Mapped drive paths instead of unc paths??? That's not an easy thing to test in environments like ours.


<p>I wish I could help but I don't have a clue.  Thinking out loud...</p><p>- Default printer issue? </p><p>- Test with the -A commandline option added (I don't hold much hope that it will make any difference)  </p><p>- Mapped drive paths instead of unc paths??? That's not an easy thing to test in environments like ours.</p>

[quote user="Joerg"]Just checked with another W10 machine. The first start, until the inbox is showing all messages, lasts 21 seconds. The seconds start takes 15 seconds.
[/quote]

 

I've got used to either fast (5 seconds) or very slow (70-90 secs) on Win7 with a similar server-based setup.

About 2 months ago I noticed a speedup of the slowest times to 15 to 20 seconds.  I've never been able to find what causes this behaviour.

<p>[quote user="Joerg"]Just checked with another W10 machine. The first start, until the inbox is showing all messages, lasts 21 seconds. The seconds start takes 15 seconds. [/quote]</p><p> </p><p>I've got used to either fast (5 seconds) or very slow (70-90 secs) on Win7 with a similar server-based setup.</p><p>About 2 months ago I noticed a speedup of the slowest times to 15 to 20 seconds.  I've never been able to find what causes this behaviour.</p>

Generally you can assume that any enhancement of security and protection (like safer hash or encryption algorithms, DNS lookups etc.) results in slower data access. I'm seeing this when opening new websites in Firefox, e.g.. Just an idea ...

Generally you can assume that any enhancement of security and protection (like safer hash or encryption algorithms, DNS lookups etc.) results in slower data access. I'm seeing this when opening new websites in Firefox, e.g.. Just an idea ... 
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

[quote user="Brian Fluet"]I wish I could help but I don't have a clue.  Thinking out loud...

- Default printer issue?

- Test with the -A commandline option added (I don't hold much hope that it will make any difference) 

- Mapped drive paths instead of unc paths??? That's not an easy thing to test in environments like ours.

[/quote] I will give them a try on Monday.

Brian, when do you plan to upgrade your machines to W10? The MS support for W7 is not everlasting but ends in near future (I think standard support ends in 2020?). That's why we have already started the upgrade process step by step one machine after the other as soon as a computer is getting retired.

[quote user="Brian Fluet"]I wish I could help but I don't have a clue.  Thinking out loud...<p>- Default printer issue? </p><p>- Test with the -A commandline option added (I don't hold much hope that it will make any difference)  </p><p>- Mapped drive paths instead of unc paths??? That's not an easy thing to test in environments like ours.</p><p>[/quote] I will give them a try on Monday.</p><p>Brian, when do you plan to upgrade your machines to W10? The MS support for W7 is not everlasting but ends in near future (I think standard support ends in 2020?). That's why we have already started the upgrade process step by step one machine after the other as soon as a computer is getting retired. </p>

I'm stuck with Win7 until the company upgrades its accounting system.  Win10 causes database corruption which we believe is due to a dependency on SMB1.

I'm stuck with Win7 until the company upgrades its accounting system.  Win10 causes database corruption which we believe is due to a dependency on SMB1.

[quote user="Brian Fluet"]

I wish I could help but I don't have a clue.  Thinking out loud...

- Default printer issue?

- Test with the -A commandline option added (I don't hold much hope that it will make any difference) 

- Mapped drive paths instead of unc paths??? That's not an easy thing to test in environments like ours.[/quote]

 Just played around a little bit with Pmail under W10. Changing the default printer and the "-A" commandline option didn't take any effect. And a mapped drive instead the UNC path is not an option for me since I have hidden both server shares, the \\servername\Pmail$\ as well as the \\servername\Mailboxes$\. My users should not see soo much drives or shared folders in the network environment.

But another thing has been turned out. Beside the new user W10 machine which is connected to LAN by cable, I make my tests on another W10 notebook (older type but already with SSD) which is connected by WLAN "n"-type. And the task manager is showing a nearly constant WLAN utilization with about 32 Mbit/s during the entire Pmail starting process. And 32 Mbit/s are not soo much when thinking about loading of folders with about 1 GByte in size. On the other hand I don't know whether Pmail is loading the entire folder content (all mails) during startup, or only the folder structure with mail headers etc. but without mail content.

Unfortunately I'm presently not able to connect this notebook by wire to compare the speed, since slim line notebooks are not longer fitted with a LAN sockets.

[quote user="Brian Fluet"]<p>I wish I could help but I don't have a clue.  Thinking out loud...</p><p>- Default printer issue? </p><p>- Test with the -A commandline option added (I don't hold much hope that it will make any difference)  </p><p>- Mapped drive paths instead of unc paths??? That's not an easy thing to test in environments like ours.[/quote]</p><p> Just played around a little bit with Pmail under W10. Changing the default printer and the "-A" commandline option didn't take any effect. And a mapped drive instead the UNC path is not an option for me since I have hidden both server shares, the \\servername\Pmail$\ as well as the \\servername\Mailboxes$\. My users should not see soo much drives or shared folders in the network environment.</p><p>But another thing has been turned out. Beside the new user W10 machine which is connected to LAN by cable, I make my tests on another W10 notebook (older type but already with SSD) which is connected by WLAN "n"-type. And the task manager is showing a nearly constant WLAN utilization with about 32 Mbit/s during the entire Pmail starting process. And 32 Mbit/s are not soo much when thinking about loading of folders with about 1 GByte in size. On the other hand I don't know whether Pmail is loading the entire folder content (all mails) during startup, or only the folder structure with mail headers etc. but without mail content.</p><p>Unfortunately I'm presently not able to connect this notebook by wire to compare the speed, since slim line notebooks are not longer fitted with a LAN sockets. </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Cancel
Delete
Pending draft ... Click to resume editing
Discard draft