Windows 7 – 64 Bit – A .NET Developer’s View

I’m currently working with Windows 7 Public Beta (Build 7000) and I’m very satisfied with it. I only had two blue screens since I have installed it 3 months ago. I would like to share some really cool features in W7 in an upcoming post and look at this video on Channel 9.

But the interesting thing from a .NET Developers perspective is the 64 Bit part of Windows 7 (that should be the same as in Windows XP 64 Bit or Windows Vista 64 Bit) which I will cover in this post.

First of all: Most of the things developing .NET are running very well. The drawbacks will be shown later…


The really cool thing of .NET is, that you now have 8 TB (Terra-Bytes) of "user mode" virtual memory per process. But wait a minute. 2^64 that’s far more than that. The memory management effort for all the 64 address lines is just too high. Therefore "only" 44 address lines are used which results in 16 TB virtual memory address space per process, where 8 TB are reserved for the OS.

But how can .NET use that address space?

Well, .NET is just doing it without recompiling your application. As you all already know there is a JIT compilation from Intermediate Language code to your real processor byte code just before the execution of the code.

Just leave your default build properties to "Any CPU" like this:


You don’t believe me? I didn’t too, so I’ve recently found a very cool tool called VMMap from SysInternals. The tool shows the truth about the memory address space of a process. For a 64 Bit .NET application that looks like this:


Even with 624 MB of virtual address space used, another 8191 GB (!) are available for your application.

How does the address space look like for a 32 Bit .NET application?

I switched to Platform target "x86" and ran the application. It looks like this:


Now only 238 MB of the virtual address space is used and 1.7 GB are free to use. It seems that the 64 Bit version needs more virtual address space than the 32 Bit version. This is quite obvious because all pointers are now doubled in size and will need more address space. So far it was only virtual address space. Someone should pick up and investigate in the real memory usage of 64 vs. 32 Bit .NET applications.

But 1.7 GB are enough for me. I don’t need 64 Bit!

  1. That is only one half of the truth. Because the virtual address space is used for different things the whole memory address space looks fragmented like your hard drive. .NET uses a memory management with 64 MB blocks which must be allocated at once. Tess Ferrandez says in one of her posts "…which means that a normal .net process will start getting OutOfMemory exceptions at around 800 MB."
  2. Even if you have 4 GB of RAM installed, Windows XP can only use about 3.3 GB depending on your hardware, because the BIOS and the addresses of your graphic card must be mapped within the 4 GB address space.

For these two reasons it is already worth to switch to 64 Bit. Isn’t it?

The drawbacks of 64 Bit

Where the sun is shining there is also shadow! I try to remember all my problems with 64 Bit and share them with you. Comments are very welcome; I will try to keep this list updated.

  • TortoiseSVN 64 Bit version wasn’t running well under Windows 7. I had several process failures. Because it is an Explorer extension it’s not easy possible to restart TortoiseSVN.
  • 64 Bit .NET applications does not support edit and continue while debugging.
  • Jet Engine is not supported for 64 Bit .NET applications anymore.
  • Some extensions does not work well with 64 Bit. E.g. PEX returns some error messages when the Platform target is "Any CPU".
  • Some Applications will not run anymore e.g. Oracle 32 Bit cannot be installed.
  • FlashPlayer doesn’t run in 64 Bit Firefox. I use the 32 Bit Version.
  • Use the latest tools from SysInternals. Some older tools caused a blue screen.
  • ALL drivers must be 64 Bit.

My configuration:

    Everything runs smoothly – much better than Vista !

About the author

Add comment

By Thomas

Recent Posts