How can we help you today? How can we help you today?

Reflector Pro and 64-bit support

While evaluating the Pro product, I have run into a road block trying to debug an executable which loads as 64-bit normally on my Windows 7 64-bit machine.

When I chose to decompile the EXE and then debug, it only loads as 32-bit, thus any DLLs it loads are 32-bit. My goal is to debug the EXE with it loading its 64-bit dependencies (which are ultimately 64-bit unmanaged DLLs).

How can I get it to decompile without losing the architecture/platform information?

VS2010 RC
Windows 7 64-bit
rstewart
0

Comments

5 comments

Sort by
  • Alex D
    I've just tried, and for me, reflector's "Debug an Executable" correctly runs things as 64 bit when they can be.

    Perhaps you could try running the exe normally so it definitely runs as 64 bit, then use Debug>Attach to process from VS to attach to it.

    Did you need to regenerate the exe to add a debug signature?

    Cheers,
    Alex D
    0
  • rstewart
    I am just trying to follow the walk through but applying it to a managed exe that loads 64-bit unmanaged dlls.

    I know at one point, a message box is displayed stating something like 'to debug, stop running the current and use the decompiled/regenerated one'.

    Sorry for the lack of detail, I am at work and performing the evaluation at home. I will try your suggestions later this evening and post back.
    rstewart
    0
  • rstewart
    Perhaps you could try running the exe normally so it definitely runs as 64 bit, then use Debug>Attach to process from VS to attach to it.

    I started the original exe normally and used Debug>Attach to attach the VS debugger and none of my break points hit. This makes since because the original has no debug signature nor pdb file.

    I then started the decompiled exe normally and started to use Debug>Attach... Before clicking the Attach button, I noticed the value of the exe in the Type column was 'Managed (v2.0.50727), x86'. At that point I knew the debugger would be attaching to the 32-bit version.

    I then chalked it up to a possible VS2010RC issue and tried VS2008TS. In doing so I forgot to close the decompiled EXE and told reflector to overwrite -- I was presented with the 'Send Error Report' dialog because Reflector crashed by not handling the exception: The process cannot access the file <path to exe> because it is being used by another process. This brought down VS2008TS.

    So in short, after the crash and restart of VS2008TS, the entire process behaved the same way by only allowing me to debug the exe as 32-bit.

    I am willing to try more suggestions or if you want to post an example with steps, I would try that as well. However, for a $195/244 USD product, this whole process should be more or less transparent - no matter the platform.
    rstewart
    0
  • Alex D
    Thanks a lot for the details, you've found a bug, and quite a bad one.

    The regeneration process reverts the CLR Header version to 2.0 instead of 2.5, which (for some reason) makes anycpu executables run as 32 bit always.

    I've put it in our bug tracking system as RP-699. We'll try to bring forward the next release to get this fixed as soon as possible.

    A workaround is to upgrade the CLR header of the regenerated assembly, using the command:
    corflags MyApplication.exe /UpgradeClrHeader
    under a Visual Studio command prompt.

    Sorry about this, and thanks for your help,
    Alex D
    0
  • rstewart
    Glad that I was of some help.

    Once the issue has been resolved and rolled into a release, can you shoot me directions on how to reset the evaluation to my register email address? I would be glad to give it another go at that point.

    Thanks
    rstewart
    0

Add comment

Please sign in to leave a comment.