PO Crashing - Possible AV Issue

We have an end user where we don't support the IT side. Pegasus has begun constantly crashing in PO Processing, it seems to be when it has printed (happens on emailing, printing or to screen) and should return to the form. It is happening to all 3 PO users

Today we have managed to see the error purely with them editing an order and then opting to publish to screen. We have used ProMon but nothing standing out at the moment

Pegasus have advised it is AV, Opera (VFP) has not been updated for a while so nothing changed there. They are using the same AV software - Cynet. IT have checked and checked that all the exclusions we have given them are still in place. There are a few other things occurred in other areas that would lead us to thinking AV or environment issue but the PO side is frequent

The error that appears is 'No table is open in the current work area., Current file is W29 and the Error Number if 53 FRMDATAMAINTENANCEFORM.ERROR

We can't recreate with data off-site or on their server which hopefully rules out issue in the data but we have investigated tables

Just wondering if anyone else have experience of Cynet and any possible suggestions

Kerry

Find more posts tagged with

Comments

claire-craig

Good morning Kerry,
That's an unusual file W29 and Error Number. 53 - don't ever recall seeing an error 53 before. I've had a look through our knowledgebase and some documents supplied by Pegasus many years ago of all the different error numbers, and that is not listed.

It's a bit suspicious it's just happening in POP if it was AV as you'd suspect seeing crashing in other modules.

I'm sure you have already done so but have you ran a POP reorganise and checked the DOHEAD and DOLINE tables for blank lines or for any lines with *** Auto
Is there any unusual files in the Company Data folder?

Regards
Claire

Kerry Hill

Hi Claire

Thanks for coming back - sorry, I did a mistype. The error number should be 52 on the information I gave

have checked doline and dohead for blank lines, uds is fine, pop reorg works fine

Regards

Kerry

DDiskel

Good Morning Kerry

One of our other customers reported the same issue last year, and in their case it was caused by the antivirus software. With that in mind, there are a few checks worth carrying out:

Are the report layout FRX files being deleted automatically? It may help to enable auditing software to identify which user or process is responsible.
Please also check whether Windows Defender is currently enabled on the machine.
Some antivirus tools apply automatic background updates that aren’t always visible, so it’s worth confirming whether any recent changes could be affecting the files.
Most likely it will be a couple of users who are crashing, but this can then lead to data corruption and create a spiral effect across the system.

Hope this helps point you in the right direction.

Kind Regards

Darps Kaur

Kerry Hill

Morning

Thank you for information supplied, much appreciated

The FRX files do not get deleted

We are fairly sure that Windows Defender was completely disabled when testing and their AV

We have also asked questions on the IT side relevant to the 3 users getting the issue in POP

The data we have interrogated as much as possible and can't see any issues. We connected to a pc editing a document and it constantly crashed (9 times out of 10), repeating same thing on server and it didn't go once. Same process with data off site and no issues found

On edit noticed they always chose to publish the order. Asked them to edit and not publish, didn't crash. We did this repeatedly and didn't crash, published to screen it crashed. It does the print job okay but the crash is when trying to come back to the form. Same when creating new orders it does the print job, its after this

Have tried amending the printer settings for user to keep pdf printer this didn't make a difference. Had previously checked if user had 'Remember Form positions and sizes on' as we discovered an issue in SE in POP Processing with this but it wasn't so ignored. Yesterday we then switched this on, Reset All and switched off again. We then edited a number of orders, published and didn't crash so left this user to see how it went

User later reported that a couple of new orders worked okay but edited quite a number and published and 50% of the time it crashed, then amended several and didn't publish and no crash

Just wondered if this extra bit of information someone might have any other thoughts

Regards

Kerry

alan-bourke

We had a lot of problems in 2023 with Purchase Orders and Microsoft Endpoint Security. Specifically MSSENSE.EXE which is a data collection executable and may also decide to have a rummage in any files that are opened. This is distinct from MSMPENG.EXE which is the antivirus file scanner. At the time to exclude files from MSSENSE a customer's Office 365 vendor had to raise a ticket with Microsoft and get them to enable an option on the endpoint security management dashboard.

Cynet may have a similar component

Copyright © 2025 Infor. All rights reserved.