.NET errors running Sage100 as RemoteApp

SOLVED

We recently (two months ago) upgraded from MAS90 4.5 to Sage100. The server has not changed: physical (not VM) Windows Server 2008 R2 Standard 64-bit, latest SPs and patches. Users ran MAS90 as a RemoteApp with no problems and are now running Sage100 as a RemoteApp, but with an occasional problem. The product appears as Sage 100 2016, and we applied the latest service pack (2, I think) shortly after initial installation to resolve some problems that arrived with the pre-SP product.The file version of our pvxwin32.exe is 9.53.51.0, with a product version of 9.53.0051.

Upon installation, we found that the service was crashing on a daily basis. The Sage explanation of the changes required to stabilize their service via tinkering with core server settings (e.g. heap) contained a big caveat that (more or less) said: "We are not responsible if our fix breaks everything else running on your server." That was the end of that. Although this is not a domain controller or Exchange server, it does host some shared files.

So instead, I am running the Application Server Startup inside an admin RD session, which I leave logged-on but disconnected at all times. This itself does not crash; however, some user will occasionally (maybe an average of once per week over the last five weeks) report that they get past their Remote Desktop logon, but when Sage100 comes up, it simply gets stuck on the white window that (at least sometimes) flashes past immediately during a successful logon.

When this occurs, a "Sage has quit responding" message pops up in the admin Remote Desktop session, and it seems that I can generally solve the problem by simply closing that window. It is too soon to know if this solves it in every case. But one thing is consistent: this pair of errors appears in the server's Application event log:

1026 .NET Runtime

 Application: pvxwin32.exe
 Framework Version: v4.0.30319
 Description: The process was terminated due to an unhandled exception.
 Exception Info: exception code c0000005, exception address 69B1125D
 Stack:

This is followed immediately by error 1000 Application error

 Faulting application name: pvxwin32.exe, version: 9.53.51.0, time stamp: 0x5628f727
 Faulting module name: MSXML4.DLL, version: 4.20.9876.0, time stamp: 0x4a6568ff
 Exception code: 0xc0000005
 Fault offset: 0x0000125d
 Faulting process id: 0x27dc
 Faulting application start time: 0x01d2401e98da3ad6
 Faulting application path: D:\Apps\Sage100_2016_Wkstn\MAS90\Home\pvxwin32.exe
 Faulting module path: C:\Windows\SysWOW64\MSXML4.DLL
 Report Id: d8842da4-ac11-11e6-b115-e0db550757ca

So it seems this is a .NET error generated by something in the program startup, but it seems to be caused by the application itself, not from .NET per se, so it seems as though I have no direct visibility to either the problem or its solution. It is never the same user twice in a row and seems entirely random.

Ideas?

  • 0
    verified answer
    Running in application mode instead of a service (or the registry hack) is necessary when you have many concurrent connections, to bypass a Windows limitation for memory with Services.

    The white screen issue (with a single ascii character in the top left corner) can be corrected by deleting and recreating some session files (sy_workstation, and three others which I will not list here because there is a multi-step process to re-create them). Sage can give you details on this, if you find someone familiar with the problem.
  • 0 in reply to Kevin M
    You can also search "white screen" in the knowledgebase to find the solution for that issue.
  • 0 in reply to Kevin M
    Thank you. That definitely gets me headed the right direction. And I appreciate the measured response, also. Too many other folks hang partially-incomplete instructions out there for all to see, and this can lead to major system problems in our largely self-serve online tech-support world these days. This level of interaction with any complex application such as Sage100 is not something that one (including me) would want to approach without a full understanding of what is required and the effect of each component. We do have a local Sage vendor that we work with, and I will call them in, since I am the information systems manager and thus not intimately familiar with the Sage file system.
  • 0 in reply to KJones44
    Ha, ha, ha! I was being too complex--starting my search on the technical side by looking for .NET-related issues, rather than the simple fact that the screen was white. I guess it is possible for too much research to be a hindrance sometimes...
  • 0 in reply to Brain
    Look up knowledge base article 19199 for the details.