Thursday, May 6, 2010

Runtime Data Isolation

One of the common mistakes done during development is to write runtime data like logs or persistent data in the folder in which the application has been installed. Its may be most convenient to write them in the root directory, but issues arise when the application has to be upgraded. Now as the installation directory also contains runtime data, we are risking loosing important historic information.

Avoid This. Make sure while designing the application, you set aside a folder outside of the root directory to write any runtime data.

Though this seems like commonsense, many a times it is forgotten during the rush.

Wednesday, May 5, 2010

Exception: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

In C# .net  3.5 64 bit platform remoting service.

This was one of those frustrating issues which takes forever to figure out what’s happening.

I have a distributed application where the web tier accesses the middle tier on a remoting service. One of the middle tier methods accepts a struct parameter. This method, when invoked from web tier on a 32 bit platform worked fine, but on 64 bit platform it threw the exception “Attempted to read or write protected memory. This is often an indication that other memory is corrupt.”

Looks like the Struct being a value type was getting messed up when passed across process boundaries through remoting. I think what was happening was the remoting service was trying to access the asp.net’s copy of struct instance. I changed the data type from struct to class and its now working fine now

VS2008 Debugging Options

Have you ever wondered why some times, the code does not work in the production environment, but works perfectly fine when you debug it in developer environment. Since the code is working in one place and not working in another, its obvious that the two are not exactly same.

Well here is the little hidden option which can make the two differ.

When “Suppress JIT optimization” you will basically be debugging NON-OPTIMIZED. And you should uncheck this option only to debug the issue which are not re-creatable in dev environment. As per Microsoft's recommendations you should leave this option checked for normal debugging.

Debugging Options