Vlad Hrybok's Tech Notes

It's very easy to write a windows service using C# or VB.NET. Easy to write, easy to install, but for a price.

It's an often overlooked fact, but in .NET runtime, Garbage Collector does not merge together freed memory chunks, if they are larger than 85K. What does it mean? It means that if your managed windows service allocates and frees buffers larger than 85K on a continuous basis, your service will crash because it will eventually run of memory due to Large Object Heap (LOH) fragmentation. Again, it will only happen if your managed windows service allocates objects of 84,000+ (give or take) byte, but IT WILL HAPPEN!

There are workarounds, somewhat expensive, like wrapping your service logic in COM+ server-activated process, which can be set up to recycle - just like IIS AppPools are recycled. Or one could create a proprietary memory manager with a pool of large buffers, making of which, of course, would be kind of ironic since the whole point of having garbage-collected memory manager was to eliminate hassles of memory management.

Anyway, the purpose of this post is to raise awareness among fellow windows service developers. If your service is high-throughput, high memory usage, it will go down in flames even if your code is perfect. The choices are: a) ensure all your memory allocations do not take more than 84K, b) implement your own memory manager, or c) implement worker process recycling.

Good luck to all of us.