2

We have a .NET 4.0 WPF client application that's downloaded and executed on hundreds of client PCs/servers daily.

We recently had a customer call our support line and report an error with one of our routines. Upon a closer investigation, I discovered that this one machine seems WAY more inclined to encounter a StackOverflow exception when executing one of our recursive algorithms.

Where as another machine with the exact same data set could complete the algorithm with 30 recursive iterations, on this machine it would fail every time before it progressed that far.

(1) Is it be possible that a certain machine (or OS configuration) is more likely to encounter StackOverflow exceptions? Why would one machine fail before 30 iterations and another go way beyond? Is something else taking up space in the "stack"?

On a possibly related note, this same customer's error log was filled with "Not enough quota is available to process this command" exceptions while trying to click on buttons, open dialogs, etc.

(2) Could these two errors point to a common cause?

The OS is Windows Server 2012.

UPDATE: I came across Why does a recursive call cause StackOverflow at different stack depths? and this definitely looks like it could possibly happen. I still can't pin-point which setting is could cause this.

Community
  • 1
  • 1
John Russell
  • 2,177
  • 4
  • 26
  • 47
  • I think that "plenty of physical memory" may be relative to how much nonsense is running on that machine, and taking up that RAM. – durbnpoisn Jun 03 '16 at 15:16
  • I don't really understand where the StackOverflow is occurring. Is it in the server code or the client code? If it is the client code the amount of memory on the server is irrelevant. – Martin Brown Jun 03 '16 at 15:25
  • The recursive algorithm is client code, but the client (in this case) is running on a server-class machine. – John Russell Jun 03 '16 at 15:26

1 Answers1

3

The stack is a limited resource, you might want to review your recursive algorithm with their particular dataset to see if there is an unusual recursion depth issue. It's possible one of their records has a circular reference.

The amount of memory available has no bearing here. The default stack size for a .NET application is 1MB. If you suspect you are only missing a bit and have no circular reference, you can use EDITBIN.EXE ( https://msdn.microsoft.com/en-us/library/d25ddyfc.aspx ) to change the assembly's stack size.

If there are memory quotas you will need to review the group policies that implement it for the particular user having the issue. It's possible the problem is a misconfiguration on the server's side.

Drunken Code Monkey
  • 1,796
  • 1
  • 14
  • 18
  • What do you mean by "memory quotas" and how could that have an impact? – John Russell Jun 03 '16 at 16:44
  • On server OSes you can define user/group-specific and machine-wide group policies defining disk and memory quotas. It is possible the memory quota is much too low for your application or user, that would be the source of your quota errors in your log. https://technet.microsoft.com/en-us/library/cc753446%28v=ws.11%29.aspx – Drunken Code Monkey Jun 03 '16 at 20:52