2

I have a C# service running as the LocalSystem account which launches numerous other processes depending on what its needs are. This has been going fine for a few months. Just this week, some of the sub-processes are crashing. I've attached a remote debugger to them, and they're failing in memory allocations (C++ new operator returns 0x0), which is the indirect cause of the crash.

Funny thing is, if I RDP into the machine, I can easily launch the process from CMD no problems. Yet when the service launches it, no go.

The machine is running Windows XP SP3. It isn't out of the commit charge is about 80% of physical RAM.

Are there some special limitations of how many processes or how much memory can be used by a service, including processes spawned by that service??

Any other ideas why these processes would be unable to allocate memory.

EDIT:

I've had a good look at the crashing scenario with Procmon from SysInternals, and it doesn't reveal anything (that I can see). It all looks like it's going normal, then suddenly crashes. I can confirm from attaching a remote debugger that it is crashing after dereferencing a null pointer from a c++ new call. This is one of the first objects allocated in the app, it should never fail.

I also discovered that if I enable to services option: Allow services to interact with desktop, then all of the child processes launch correctly. The do, however, appear on the desktop when you connect via RDP and are unfortunately terminated if you log out via RDP = YUK! This still isn't an ideal solution, though - I'd really like to know why the child processes were unable to allocate memory after the 6th child process.

Matt Connolly
  • 9,757
  • 2
  • 65
  • 61
  • Please add to the post the error messages in the Event Viewer from these crashes. – harrymc Oct 02 '11 at 12:27
  • The only message in the Event Log is from the debugger failing to load then the app crashes (reading an inaccessible address): "An unhandled win32 exception occurred in MDS_16.exe [456]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on. Check the documentation index for 'Just-in-time debugging, errors' for more information. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp." – Matt Connolly Oct 02 '11 at 12:52
  • As I mentioned before, I can remote debug into the process that crashes, and there's a C++ new call returning null, which is being dereferenced, cashing the crash. The real problem is that the process is unable to allocate memory to get started. – Matt Connolly Oct 02 '11 at 12:53
  • I understand the processes have a graphical interface even while run a service. So better check them for kernel-objects usage. In Task Manager, Processes tab, menu View / Select ..., add Working set (Memory) & Handles & Threads & USER Objects & GDI Objects. Look for steadily incrementing counters, and especially when a crash happens, as there is an upper limit for these. – harrymc Oct 02 '11 at 14:58
  • Have you implemented your own `operator new`, or are you using the `operator new` provided by the CRT? – ta.speot.is Oct 08 '11 at 08:52

3 Answers3

5

I hope this answer will help somebody in the future... I had the same problem - apps would run fine if windows were allowed to render, but would crash on startup if ran under a service and not allowed to interact with desktop. The solution lies in increasing the size of non-interactive windows station heap in the registry, which was set to 512KB on my machine while interactive windows station heap was 3072KB.

You can change this by going to

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

The value is a long string. You need to change the SharedSection setting which looks something like this:

SharedSection=1024,3072,512

The second number is size of interactive windows station heap and the last one is size of non-interactive windows station heap. If you delete the last number then interactive and non-interactive windows station heaps will be of the same size. That's what I did.

Read the details here: http://support.microsoft.com/kb/184802

Mahm00d
  • 3,881
  • 8
  • 44
  • 83
Andreja Zitnik
  • 66
  • 1
  • 4
  • The machine which I experience the problem on is now dead. We've worked around the problem, by including the functionality in another already running service. But, I'll give you benefit of the doubt on this one!! – Matt Connolly Sep 12 '12 at 04:06
1

Are there some special limitations of how many processes or how much memory can be used by a service, including processes spawned by that service??

Job objects can be used to restrict the memory usage of a process (or group of processes), but something would need to associate the processes in question with that job object.

There is no such job object for service processes.

Consider using the registry to allow you to debug from the start-up of the affected processes: http://msdn.microsoft.com/en-us/library/a329t4ed.aspx

Richard
  • 106,783
  • 21
  • 203
  • 265
  • Because this is a remote machine, setting the environment to automatically debug with JIT doesn't work. Additionally, the processes are run as the LocalSystem use, which JIT debugger can't launch because the user has no console. I've already managed to attach a remote debugger to the application and can see that it's failing to allocate memory with c++ new operator returning NULL. Hence the question about memory limits which might be the cause of this... – Matt Connolly Sep 23 '11 at 04:46
1

You might find SysInterals Procmon useful for seeing what's going on with your processes.

jdigital
  • 11,926
  • 4
  • 34
  • 51
  • I had a good look at Procmon while I have a process crashing. I don't see anything that points to why it would fail to allocate memory. There's a bunch of DLLs loading and registry queries. Then it starts loading the jit debugger - which is in response to the crash from dereferencing the null pointer from a failed memory allocation. :( – Matt Connolly Sep 30 '11 at 11:17