An Exercise in Virtual to Physical Memory Translation

Monday, September 23, 2013

In this post, we will explore virtual address translation through a real-world example. If you’d like, the instructions here should be sufficiently detailed for you to perform this experiment on your own, with a kernel debugger (a local kernel debugger session or even LiveKD is sufficient). Let’s start with the basics. For a great walkthrough of how memory translation works on x86-64 and x86, you should read Luke Hutchinson’s blog post. Alternatively, Windows Internals (6th edition) contains an even more detailed description of address translation in the Memory Manager chapter (volume 2). Now let’s go ahead and...
no comments

Obtaining Reliable Thread Call Stacks of 64-bit Processes

Wednesday, May 15, 2013

The x64 calling convention is a great improvement over the state of affairs in x86. Few would argue about this. After all, remembering the differences between __stdcall and __cdecl, when to use each, which API defaults to which calling convention, and which specific variation of __fastcall JIT compilers use when given the choice -- is not the best use of developer time and not the best in terms of debugging productivity. With that said, the x64 calling convention often makes it very difficult to retrieve parameter values from the call stack if you don't have private symbols for the relevant...

What AnyCPU Really Means As Of .NET 4.5 and Visual Studio 11

Wednesday, April 4, 2012

The 32-bit and 64-bit development story on Windows seemingly never stops causing problems for developers. It’s been a decade since 64-bit processors have started popping up in the Windows consumer environment, but we just can’t get it right. If you forget some of the gory details, here are a couple of reminders: On a 64-bit Windows system, both the 32-bit and 64-bit versions of system DLLs are stored. The 64-bit DLLs are in C:\Windows\System32, and the 32-bit DLLs are in C:\Windows\SysWOW64. When a 32-bit process opens a file in C:\Program Files, it...

The Case of the Unit Test and the Native DLL

Saturday, August 28, 2010

I got an email from a former client a couple of days ago with roughly the following problem description: I’m trying to run a unit test (with MSTest) which calls an interop function. The native DLL (written in C) is located in C:\Windows\System32. For some reason, when running the test Visual Studio can’t seem to find the DLL, and throws a FileNotFoundException. Moreover, I can’t even see the DLL in the File—>Open dialog in Visual Studio! I tried launching Visual Studio as admin and as standard user but the result was the same. What am I missing...
no comments

Tales from High Memory Scenarios: Part 2

Wednesday, January 28, 2009

In the first part, we looked at a scenario where fiddling with the in-memory field controlling a custom cache size and then externally triggering a garbage collection gave us a likely culprit for a high memory scenario. After having disentangled the first problem, we faced a completely different issue.  One of the apparently-leaking processes didn’t have that many objects in its managed heap.  Inspecting the GC performance counters indicated that there while memory utilization was around 900MB, only 150MB or so of managed objects were actually on the managed heap. We ran the !eeheap –gc WinDbg command...
no comments

Tales from High Memory Scenarios: Part 1

Tuesday, January 27, 2009

A few days ago, I was visiting a customer with high-memory scenarios in a 64-bit ASP.NET application.  I’m saying “scenarios” because we still don’t know for sure what the problem was, and because we’re pretty confident that there’s more than one underlying cause. Even though there are no conclusive results yet, I wanted to share with you some of the things we did because they are interesting on their own behalf. What we were facing was a set of 4 w3wp.exe processes that were consistently increasing in memory consumption over a period of several hours, starting from...
no comments

PDC Day 3: What’s Coming in CLR 4.0 (Part 2)

Thursday, October 30, 2008

In part 1 we looked at CLR side-by-side support for multiple versions, at interoperability-related features and at DLR-related changes in the CLR. There have been various complaints about performance aspects of the CLR that are sometimes neglected - the installation experience, the startup experience and the GC latency experience for high-performance applications.  This feedback will be addressed in CLR 4.0: The .NET installer can be branded and customized, and begins with a 200K bootstrapper.  Downloading, installing and NGEN-ing the framework all occur in parallel, enabling a faster setup experience with less clicks to install. Startup improvements (around cold...

The Case of RegSvr32 and the Haunted DLL

Saturday, June 28, 2008

Last week I've resolved a simple "debugging" case by phone, and figured that it might benefit putting it online.  Here's the approximate outline of the call: Customer: Sasha, we have a COM component registration that is failing because regsvr32 says it can't find the DLL. Myself: Where is it looking for that DLL? Customer: It doesn't matter where it's looking.  We put the component in the System32 directory, but it still complained that it can't find it. Myself: Is it a 64-bit system and you're trying to register a 32-bit component?  You should...
no comments

Non-Paging CLR Host

Friday, June 27, 2008

I've just uploaded a new open-source project called "Non-Paged CLR Host" to CodePlex, in collaboration with Alon Fliess.  This project features a custom CLR host that can be used for executing any existing .NET application with little or no modification.  This custom CLR host ensures that all memory given out to the CLR is locked into physical memory if possible, thus eliminating paging completely. This can provide two important and distinct advantages to server and client applications alike: Applications will benefit from no paging during normal operation.  Even if other applications are actively allocating memory, allocations performed under...