Insufficient pagefile size can cause obscure memory errors

Today, a user reported an issue connecting to a very old CRM application. I logged in to the system myself and saw no error. Since I’m not happy with self-healing issues, I went digging into the event log on the server.

For the past five days, there have been over 15,000 entries added to the System event log with event ID 333: “An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system’s image of the Registry.” That doesn’t sound good.

My first stop for analyzing event log errors is The feedback on their site pointed me to a few possibilities.

  • The /3GB switch on a system with 2GB or less of memory.
  • Symantec AntiVirus (which is a potential culprit to every system problem, apparently).
  • Insufficient Non Paged Memory or Paged Pool Memory.
  • Disk or I/O subsystem errors.
  • Overaggressive SQL Server memory usage or I/O affinity.

I checked the server’s memory capacity: 3GB. I checked memory usage in Task Manager: about the same. I checked the page file size, and saw the following (note the highlighted sections).

Ouch! Microsoft has a nice knowledge base article, affectionately titled, RAM, Virtual Memory, Pagefile, and all that stuff, which suggests, as a baseline recommendation, that a pagefile should equal “1.5 times the amount of RAM that is in the computer.” As always, your mileage may vary, but generally speaking, the recommendation is sound. Or, you can just click the “System managed size” option, and forget about it altogether.

The lesson here: check your pagefile settings when setting up a computer, and always revisit them whenever the amount of physical RAM changes.

A practical definition of C# constructors

What’s the textbook definition of a constructor in C#? According to Microsoft (emphasis added):

Whenever a class or struct is created, its constructor is called. A class or struct may have multiple constructors that take different arguments. Constructors enable the programmer to set default values, limit instantiation, and write code that is flexible and easy to read.

That’s not a great definition, but it tells us some important things:

  • There can be many constructors.
  • Constructors may or may not have parameters.
  • Constructors should be used to:
    • set default values,
    • perform limited initialization, and
    • be simple.

In other words, constructors should do as little as possible.

Constructors should:

  • initialize fields and properties
  • check the runtime configuration and environment
  • fail if the object can not be set up properly
  • be consistent, in therms of logic (when using multiple constructors)
  • be thread-safe

Constructors should not:

  • invoke complex business logic (example)
  • use out parameters (example)
  • accept arrays, except as params (use collection types instead)

I’m sure there is more, but those are my guidelines.