Errorlog.txt: Attempted to read or write protected memory.

[Wayne]

I have LS3 running on 2003 Standard SP2 (VM in an ESX cluster) that is having some issues. Clients are connecting, getting scanned, and reports work fine for the most part, but the Lansweeper service crashes every so often with the following entered in the errorlog.txt:


2/13/2008 8:15:24 AM
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.


The Application event log contains:

Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 1000
Date: 2/13/2008
Time: 8:15:25 AM
User: N/A
Computer: XXXXXXXXX
Description:
Faulting application lansweeper30.exe, version 3.0.0.0, stamp 47945fac, faulting module msvcr80.dll, version 8.0.50727.1433, stamp 471eb5ae, debug? 0, fault address 0x000150d8.

Anyone else having issues with the service crashing? This is the only VM with issues with over 40 VMs on the ESX cluster, so I do not believe it is hardware related.

[Hemoco]

It all depends on your "wait times", different time zones for different locations (when do people log on) and how many pc's need to be scanned for the first time (takes most time/bandwith)
The best performance boost can be gained by adding more virtual processors / faster network connection.

[Wayne]

What type of CPU utilization are you seeing on your Lansweeper VM? In the morning when the majority of folks log in, I'm seeing the CPU utilization for the VM spike up quite a bit (1-1.5GHz average for an hour or two). Disk usage is zilch and network usage maxes at 500 KBps according to vcenter. Average network usage is 62KBps over a 24-hour period, but the morning log-in hours it averages roughly 300KBps.

[Hemoco]

I'm also running on a vmware esx cluster with 40 threads at this moment, but I tested with 64 threads without any problems.

[Wayne]

Yes, all patches have been applied for the OS and .NET framework. I did lower the # of threads to 20 which seems to have fixed the problem. I believe I had configured 50 threads originally since we have about 4000 clients on our network. 1,720 clients have been scanned since the change without the service crashing.

[Hemoco]

I must say that I never seen this problem before, as the dotnet framework manages the memory.
Does the dotnet framework has the latest servicepack?