Ranorex Forum

I have solutions that I developed some time ago and have maintained for a year or more, meaning I've opened them, modified them, and run them at least once every three months. On a couple of these, I even worked on them just last week. This morning I opened one of the solutions and got this message: "The process to debug is incompatible with the current studio platform, i.e. "x64" or "x86" platform targets must match. Ranorex Studio needs to be restarted with the same process architecture. Do you want to restart Ranorex Studio?" When I restarted, it started Studio in 32 bit mode. I don't work in 32 bit mode and I've never developed in 32 bit mode. I closed the 32 bit mode down and reopened the 64 bit Studio. After some searching on the internet, I went into the project properties and changed the target CPU from 32-bit Intel-compatible processor to 64-bit, and had no more problems.

This afternoon, I opened another solution to work on, and got the same message. Now, I could go in and make the same change to the target CPU, but I'm concerned: why is this happening? I haven't upgraded Ranorex (currently on 9.0.1). I haven't changed any settings like the target CPU. I was just working on these solutions a few days ago. Why has the target CPU setting changed all of a sudden? Am I going to run into this same problem with every solution I open?

Hi,

The problem you are describing, is caused by an attempt to debug 64bit solution in 32bit Studio! 32bit Ranorex Studio does not allow debugging of 64-bit based projects!

karltinsly wrote: ↑

Mon Nov 18, 2019 11:06 pm

This morning I opened one of the solutions...

How exactly did you open the solution? Because if you simply double-clicked rxsln file, such action (by default) starts 32bit Studio! So, even if your project was originally created with 64bit Studio, loading it in 32bit Studio makes it impossible to debug.

Also, 64bit Studio is available since 9.0. So any project created before, was, most probably, created as 32bit one (unless target CPU was manually set to 64bit). And even after 9.0 release, Ranorex Studio, by default, starts in 32bit mode and you must explicitly select and start 64bit version of the Studio. So make sure you always start 64bit Studio and do not use double click on rxsln, to start the Studio

Thanks for your reply. I agree, if opening by double-clicking the solution, it will open in the 32-bit studio. However, I'm opening 64-bit studio first, and opening the solution from list of recent projects.

Is there anything else that could cause this problem?

I should mention something else: after I went into project properties and changed the target CPU to 64-bit, I tried to run it again. I got a message that said the process to run requires higher privileges. Ranorex Studio needs to be restarted as Administrator.

Like the other error, I have never seen this message before. I have been developing Ranorex scripts on this machine for well over a year. I'm working on scripts that ran fine just last week. I haven't changed any settings, as far as I know - however, there have been windows updates, and our enterprise remote manages some settings and properties, so I guess it's possible they did something I'm not aware of. I'm just hoping to find out what sorts of things could trigger these errors.

Hi,

Debugging mode always required Ranorex Studio to be run as Administrator! As far as I know, nothing has changed in this matter in recent Ranorex updates. The only explanation why you did not see this error before is, that you've most probably started Ranorex Studio as Administrator?

So, the conclusion is...
1) Debug mode requires Studio to be started as Administrator.
2) Solution with Target CPU set to 64bit cannot be debugged in 32bit Studio.

As I mentioned in previous post, Ranorex Studio, by default, starts in 32bit mode and as non-admin. So if you want to debug 64bit solution, you must start 64bit Studio and as Administrator. Both problems could be solved by creating simple shortcut, which starts 64bit Studio and as Admin I'm afraid, there is no other solution.

Okay, thank you.