can't load dump from x64 machine

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
Qythyx
Posts: 5
Joined: Wed Aug 19, 2009 2:59 am

can't load dump from x64 machine

Post by Qythyx » Thu Nov 12, 2009 6:32 am

I'm trying to load a dump file that was running as a 32 bit process on a x64 machine. When I try to I get the dialog that shows symbols loading, but then another window pops up saying ".NET Runtime Versions Mismatch". It says "the correct version of the .NET runtime file MSCORDACWKS.dll must be available."

The machine which created the dump is Windows Server 2008 R2 (x64). The machine I'm trying to use to analyze the dump on is Windows 7 (x64). As far as I can tell both machines are running the exact same version of .NET, so I don't understand why I'm getting this error in the first place.

I tried coping the mscordacwks.dll file from the machine that created the dump, but that didn't help. It's not clear whether it's looking for the x86 or x64 versions, so I tried copying both as:

mscordacwks_x64_x64_2.0.50727.4927.dll
and
mscordacwks_x86_x86_2.0.50727.4927.dll


I noticed that when trying to load the dump into WinDbg I initially had an error there as well. To correct that I had to issue these WinDbg commands, afterwhich it was fine:
1. .load wow64exts
2. !sw



So, any ideas? Also, it would be really useful if this error could say what architecture and version it is looking for.

Andreas Suurkuusk
Posts: 1006
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Fri Nov 13, 2009 9:35 am

The mismatched runtime version message appears when .NET Memory Profiler has failed to load the memory dump file for some reason. The profiler assumes (sometimes not correctly) that it has failed to locate the correct mscordacwks file. In your case, the problem probably occurs because you have created a 64-bit memory dump of a 32-bit process (e.g. by using the Task manager?) . Previously, it was not possible to analyse .NET memory in such dump files, but with Debugging Tools v6.10.3.233, or later, this is now possible.

So we have updated .NET Memory Profiler to allow these type of memory dumps files to be imported. We have also updated the mismatched runtime version message, so that it includes information about what version of mscordacwks.dll it is looking for. Finally, you now specify the mscordacwks file itself, and not its folder (unlike WinDbg, the actual name of the file is not important). See screenshot below.
Image

We have not yet released an official version containing the changes described, but you can download a pre-release from:

http://memprofiler.com/MemProfilerInstaller3_5_111.msi (or http://memprofiler.com/MemProfilerInsta ... -64bit.msi for the 64-bit version).

We still have to do some additional testing before releasing the official version. We will also add some extra checks before importing a memory dump file, e.g. we will inform the user that a 64-bit dump containing a 32-bit process cannot be imported unless Debugging Tools v6.10.3.233, or later is installed.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Qythyx
Posts: 5
Joined: Wed Aug 19, 2009 2:59 am

Post by Qythyx » Mon Nov 16, 2009 3:57 am

Thanks for the update on this. I tried the new version, and it no longer shows an error when opening the dump, but I have a new problem. After the dump is analyzed there are no results. No types are listed at all.

I tried 2 different dumps, both were created via Task Manager, and both have this problem.

BTW, these dumps are from IIS' w3p process because I'm trying to analyze a ASP.NET issue.

Any ideas?

Andreas Suurkuusk
Posts: 1006
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Mon Nov 16, 2009 9:38 am

If the memory dump file is created at a bad time, e.g. during a GC when managed memory is being rearranged and book-keeping data updated, then the profiler can fail to import the memory dump. However, it's unlikely that this would happen for two different memory dump files.

If the memory dumps can be analyzed using WinDbg and SOS, then .NET Memory Profiler should be able to import them. Can you test whether the memory dumps for in WinDbg by following the steps below?
  1. Start 32-bit WinDbg and open the memory dump file.
  2. Load wow64exts: ".load wow64exts"
  3. Switch to 32-bit mode: "!sw"
  4. Load SOS: ".loadby sos mscorwks"
  5. Issue an SOS command: "!EEHeap"
  6. If the EEHeap command worked, try to dump the heap (which might take a long time): "!DumpHeap"
If you get information about the memory dump by following the steps above, then .NET Memory Profiler should also be able to import it. In this case, it would be very good if we could investigate the memory dumps ourselves, to find out what the problem is. If it's possible for you to provide us with a memory dump, please contact us at support@scitech.se for information on how to send the files to us.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Andreas Suurkuusk
Posts: 1006
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Mon Nov 16, 2009 10:36 pm

Thanks for sending us the memory dump file. Unfortunately, the dump file cannot be loaded into .NET Memory Profiler (and it can only be partially analyzed using WinDbg/SOS). The problem is that the IIS worker process (W3WP) is flagged as LARGEADDRESSAWARE, which will cause memory addresses over 2 GB to be used ( > 0x7fffffff). And it seems like 32-bit memory dumps created by the 64-bit Task manager don't include memory data over 2GB.

To solve this you will need to create the memory dumps using a 32-bit program, e.g. the ADPlus script included with he 32-bit debugging tools.

We will continue to investigate this, and we will at least modify .NET Memory Profiler so that it informs the user that the memory dump cannot be imported (and why). We will also add a small utility program that can be used to create memory dump files, without requiring the Debugging Tools.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Qythyx
Posts: 5
Joined: Wed Aug 19, 2009 2:59 am

Post by Qythyx » Tue Nov 17, 2009 12:31 am

Ok, thanks for looking into this. I'll try ADPlus next time I get a repro of the problem we're working on. If I still have issue analyzing the dump after that I'll let you know.

TomGorks
Posts: 1
Joined: Thu Nov 18, 2010 1:37 pm

Re: can't load dump from x64 machine

Post by TomGorks » Thu Nov 18, 2010 1:39 pm

Thanks for the update on this. I tried the new version, and it no longer shows an error when opening the dump, but I have a new problem. After the dump is analyzed there are no results. No types are listed at all.

When is the next update?

Is it possible to do the 3 Week Diet from https://skinnyexpress.com/the-3-week-diet-review before running a marathon?
Last edited by TomGorks on Tue Dec 22, 2015 5:41 pm, edited 4 times in total.

Andreas Suurkuusk
Posts: 1006
Joined: Wed Mar 02, 2005 7:53 pm

Re: can't load dump from x64 machine

Post by Andreas Suurkuusk » Fri Nov 19, 2010 4:38 pm

As has been mentioned in a previous reply, there is a risk that the memory dump file is created at a bad time, e.g. during a GC when managed memory is being rearranged and book-keeping data updated. In this case the profiler can fail to import the memory dump. The current version does not detect this problem and the import will appear to succeed, but the "Types" list will be empty. In the next version (.NET Memory Profiler 4.0) we will try to detect bad memory dumps, but unfortunately we will problably still not be able to retrieve any information, just present information about the problem

If possible, it would be good if we could take a look at your memory dump file, so that we can analyse whether it is actually a bad memory dump, or if there's a problem in the profiler. If you can send the memory dump to us, please contact us at support@scitech.se and I will provide you with information on how to upload the file to us.
Best regards,

Andreas Suurkuusk
SciTech Software AB

BerythaBeasley
Posts: 1
Joined: Fri Jun 15, 2018 9:54 am

Re: can't load dump from x64 machine

Post by BerythaBeasley » Fri Jun 15, 2018 9:56 am

If you want to analyze a 64-bit process dump then you need to run the 64 bit version version of the debugger on a 64-bit machine. A dump from 32-bit process can be analyzed on 32-bit and 64-bit machine. So if you are sure the dump is from 64-bit process, it needs to be analyzed on 64-bit machine.

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests