Search found 7 matches

Thanks. That did the trick!!

We are installing PageGate on a VMWare Server running Win2k3 Enterprise. All was going well until we got to the SNPP in setup. All the other modules (getmail, getweb, getascii, gui) run with no problem. The snpp module, however returns a kernal32 error.

Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 4/27/2010
Time: 3:58:16 PM
User: N/A
Computer: PAGEGATE
Description:
Faulting application SnppServer.exe, version 5.0.92.0, faulting module kernel32.dll, version 5.2.3790.4062, fault address 0x0000bee7.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 53 6e 70 ure Snp
0018: 70 53 65 72 76 65 72 2e pServer.
0020: 65 78 65 20 35 2e 30 2e exe 5.0.
0028: 39 32 2e 30 20 69 6e 20 92.0 in
0030: 6b 65 72 6e 65 6c 33 32 kernel32
0038: 2e 64 6c 6c 20 35 2e 32 .dll 5.2
0040: 2e 33 37 39 30 2e 34 30 .3790.40
0048: 36 32 20 61 74 20 6f 66 62 at of
0050: 66 73 65 74 20 30 30 30 fset 000
0058: 30 62 65 65 37 0bee7

Any thoughts on this?

This is the first installation I have done on an Enterprise edition server and wonder if this is the issue. Also this is the my first installation of this program on a vmware server, but I have never had issues with other software on this type of platform.

I have been working with Notepage on this issue. I am bginning to believe that database size may have a bearing on this. I have since reduced the archive to 30 days from previous higher levels and we seem to have stablized. We are watching the perfomance very closely and running debug logging to try and catch any anomolies.

We are fairly large West Coast regional paging carrier and probably handle much higher traffic than most uers.

If you are having an issue, I strongly reccomend that you run Notepage Pro in conjuction with the pagegate monitor to alert you if any of the services lock up during the midnight roll over. This works quite well.

I've been running 5.0.8, but just moved my server with the lowest MX priority up to 5.0.9 at Notepages request. On Monday I will change MX priority to make this the highest priority server for test.

Also, I was logging detail but just changed to summary. Archive is set, so max file size is not applicable. File size is whatever daily size is. This is typically 4 to 6 MB total logging less badmsg log. After changing to summary, this total logging has dropped by about 60%. This may be an interim solution, but the fact still remains that the connector should not rollover and die based on log size.

There is no documentation that I have found concerning perfomance degradation based on logging level, however, I still feel that the log size in this configuration is the trigger. The connector failure occurs when we have had a high traffic day. 9MB or higher total logging for the day. Keep in mind that we pre filter all incoming SMTP traffic for spam.

I should mention that the only paging traffic that we run through these machines is mostly ADHOC SMTP with some alias addressing. We do not use the Web or client interface. Our SMTP traffic is probably far higher than the average Pagegate user. We are a major west coast regional paging carrier.

Also, Our connectors are set up for snpp and send to snpp servers on our LAN.

NotePage is now working with us and hopefully we will get to the bottom of this issue soon.

Good luck in getting this resolved. I have been fighting this for over a year. All I have ever gotten is "update to the latest build". This has never resolved the issue.

We run 2 dedicated recent production Dell servers and still have the problem. This is the third set of servers and we have run the program on Win2K WS, Win2k Server, and most recently Win2K 2003.

My observations have been that the failure is most likely to occur when the combined daily log file and badmsg file sizes climb to unusual levels. In my most recent cases this was 9MB on one occasion and 11MB on another occasion. I do run all incoming traffic through our corporate gateway to remove as much spam as possible before it hits the servers. If I didn't do that, I suspect pagegate would fail every night.

In order to reduce the log file size, I have taken the following steps.

I run a scheduled batch job to dump the contents of the badmsg file at 11 PM every night. This seems to have made a big difference in the failure rate. In my case, if these messages failed once, requeuing them for retry is not going to get them to go. This file, for us at least, can get quite large over a several day period. If you are not filtering for spam on the front end, I suppose it can become enormous.

Most recently I changed logging level from detail to summary. I do not have enough time with this setting to clearly state whether this will make a difference. However, if I am correct, this should make a dramatic difference. I checked the documentation, an find nothing that mentions performance degradation based on logging level, but experience dictates that the more logging, the greater the impact on performance.

My opinion is that this product for all the other nice features and the general good job that it does, does have this one stability issue that needs to be addressed.

I searched the forum on this issue and found one other reference to this exact same issue, but no response on it either. I have had complaints of missed and delayed pages as well as emails not forwarding.

Has anyone else seen or resolved this issue?

I am getting this Application event error every day at midnight

Event Type: Error
Event Source: PGMailServer.exe
Event Category: None
Event ID: 1
Date: 2/5/2008
Time: 12:00:16 AM
User: N/A
Computer: PAGEGATE
Description:
The description for Event ID ( 1 ) in Source ( PGMailServer.exe ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: Access violation at address 004BE2C7 in module 'PGMailServer.exe'. Read of address 00000000.

Also, the Pagegate software appears to just stop occasionally and has to be restarted. Sometimes, the server has to be rebooted.

We are running Windows 2000 servier with all the current updates, Pagegate 5.0.6 on a p4 2.8 processor and 1 GB of ram.

Any thoughts on this?

Author	Message
Topic: SNPP In Module on VMWare Win2k3 Enterprise
tordaan Replies: 2 Views: 9741	Forum: PageGate Support Posted: Wed Apr 28, 2010 11:37 am Subject: SNPP In Module on VMWare Win2k3 Enterprise
tordaan Replies: 2 Views: 9741	Thanks. That did the trick!!
Topic: SNPP In Module on VMWare Win2k3 Enterprise
tordaan Replies: 2 Views: 9741	Forum: PageGate Support Posted: Tue Apr 27, 2010 6:51 pm Subject: SNPP In Module on VMWare Win2k3 Enterprise
tordaan Replies: 2 Views: 9741	We are installing PageGate on a VMWare Server running Win2k3 Enterprise. All was going well until we got to the SNPP in setup. All the other modules (getmail, getweb, getascii, gui) run with no problem. The snpp module, however returns a kernal32 error. Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 4/27/2010 Time: 3:58:16 PM User: N/A Computer: PAGEGATE Description: Faulting application SnppServer.exe, version 5.0.92.0, faulting module kernel32.dll, version 5.2.3790.4062, fault address 0x0000bee7. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 53 6e 70 ure Snp 0018: 70 53 65 72 76 65 72 2e pServer. 0020: 65 78 65 20 35 2e 30 2e exe 5.0. 0028: 39 32 2e 30 20 69 6e 20 92.0 in 0030: 6b 65 72 6e 65 6c 33 32 kernel32 0038: 2e 64 6c 6c 20 35 2e 32 .dll 5.2 0040: 2e 33 37 39 30 2e 34 30 .3790.40 0048: 36 32 20 61 74 20 6f 66 62 at of 0050: 66 73 65 74 20 30 30 30 fset 000 0058: 30 62 65 65 37 0bee7 Any thoughts on this? This is the first installation I have done on an Enterprise edition server and wonder if this is the issue. Also this is the my first installation of this program on a vmware server, but I have never had issues with other software on this type of platform.
Topic: PageGate stop at Midnight...
tordaan Replies: 6 Views: 18171	Forum: PageGate Support Posted: Wed Feb 25, 2009 2:48 pm Subject: PageGate stop at Midnight...
tordaan Replies: 6 Views: 18171	I have been working with Notepage on this issue. I am bginning to believe that database size may have a bearing on this. I have since reduced the archive to 30 days from previous higher levels and we seem to have stablized. We are watching the perfomance very closely and running debug logging to try and catch any anomolies. We are fairly large West Coast regional paging carrier and probably handle much higher traffic than most uers. If you are having an issue, I strongly reccomend that you run Notepage Pro in conjuction with the pagegate monitor to alert you if any of the services lock up during the midnight roll over. This works quite well.
Topic: PageGate stop at Midnight...
tordaan Replies: 6 Views: 18171	Forum: PageGate Support Posted: Fri Dec 26, 2008 3:54 am Subject: PageGate stop at Midnight...
tordaan Replies: 6 Views: 18171	I've been running 5.0.8, but just moved my server with the lowest MX priority up to 5.0.9 at Notepages request. On Monday I will change MX priority to make this the highest priority server for test. Also, I was logging detail but just changed to summary. Archive is set, so max file size is not applicable. File size is whatever daily size is. This is typically 4 to 6 MB total logging less badmsg log. After changing to summary, this total logging has dropped by about 60%. This may be an interim solution, but the fact still remains that the connector should not rollover and die based on log size. There is no documentation that I have found concerning perfomance degradation based on logging level, however, I still feel that the log size in this configuration is the trigger. The connector failure occurs when we have had a high traffic day. 9MB or higher total logging for the day. Keep in mind that we pre filter all incoming SMTP traffic for spam. I should mention that the only paging traffic that we run through these machines is mostly ADHOC SMTP with some alias addressing. We do not use the Web or client interface. Our SMTP traffic is probably far higher than the average Pagegate user. We are a major west coast regional paging carrier. Also, Our connectors are set up for snpp and send to snpp servers on our LAN. NotePage is now working with us and hopefully we will get to the bottom of this issue soon.
Topic: PageGate stop at Midnight...
tordaan Replies: 6 Views: 18171	Forum: PageGate Support Posted: Wed Dec 24, 2008 4:15 am Subject: PageGate stop at Midnight...
tordaan Replies: 6 Views: 18171	Good luck in getting this resolved. I have been fighting this for over a year. All I have ever gotten is "update to the latest build". This has never resolved the issue. We run 2 dedicated recent production Dell servers and still have the problem. This is the third set of servers and we have run the program on Win2K WS, Win2k Server, and most recently Win2K 2003. My observations have been that the failure is most likely to occur when the combined daily log file and badmsg file sizes climb to unusual levels. In my most recent cases this was 9MB on one occasion and 11MB on another occasion. I do run all incoming traffic through our corporate gateway to remove as much spam as possible before it hits the servers. If I didn't do that, I suspect pagegate would fail every night. In order to reduce the log file size, I have taken the following steps. I run a scheduled batch job to dump the contents of the badmsg file at 11 PM every night. This seems to have made a big difference in the failure rate. In my case, if these messages failed once, requeuing them for retry is not going to get them to go. This file, for us at least, can get quite large over a several day period. If you are not filtering for spam on the front end, I suppose it can become enormous. Most recently I changed logging level from detail to summary. I do not have enough time with this setting to clearly state whether this will make a difference. However, if I am correct, this should make a dramatic difference. I checked the documentation, an find nothing that mentions performance degradation based on logging level, but experience dictates that the more logging, the greater the impact on performance. My opinion is that this product for all the other nice features and the general good job that it does, does have this one stability issue that needs to be addressed.
Topic: PGMailServer.exe Every Day at Midnight
tordaan Replies: 2 Views: 9998	Forum: PageGate Support Posted: Mon Feb 11, 2008 3:44 pm Subject: PGMailServer.exe Every Day at Midnight
tordaan Replies: 2 Views: 9998	I searched the forum on this issue and found one other reference to this exact same issue, but no response on it either. I have had complaints of missed and delayed pages as well as emails not forwarding. Has anyone else seen or resolved this issue?
Topic: PGMailServer.exe Every Day at Midnight
tordaan Replies: 2 Views: 9998	Forum: PageGate Support Posted: Tue Feb 05, 2008 1:38 pm Subject: PGMailServer.exe Every Day at Midnight
tordaan Replies: 2 Views: 9998	I am getting this Application event error every day at midnight Event Type: Error Event Source: PGMailServer.exe Event Category: None Event ID: 1 Date: 2/5/2008 Time: 12:00:16 AM User: N/A Computer: PAGEGATE Description: The description for Event ID ( 1 ) in Source ( PGMailServer.exe ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: Access violation at address 004BE2C7 in module 'PGMailServer.exe'. Read of address 00000000. Also, the Pagegate software appears to just stop occasionally and has to be restarted. Sometimes, the server has to be rebooted. We are running Windows 2000 servier with all the current updates, Pagegate 5.0.6 on a p4 2.8 processor and 1 GB of ram. Any thoughts on this?