Can't build 64bit applications

I’ve got two Windows 10 development computers and neither of them can build XoJo x86-64 applications. The builds lock up at “Linking”. So then I loaded 2019r1.1 onto my Windows 10 notebook. I can build the sample project ServerSocketClientTest in x86-64. So then I went back to the Dev PC’s and used the same example project ServerSocketClientTest and both still lockup at linking.

Notebook is Windows 10 build 1607, Dev PC 1 is Windows 10 build 1903 and Dev PC 2 is Windows 10 build 1803. I then start worrying about a conflicting application - like both Dev PC’s have Visual Studio 2015 loaded. All three have Adobe Creative Cloud, so that’s not it.

This is the first time I’ve jumped into the x64 realm, so I went back to 2018r4 and opened the same Examples project ServerSocketClientTest and I can’t build this in x86-64 either (again, locks up at Linking).

You might want to disable any virus detection software and see if that helps. I had a similar problem… 32 bit worked but 64 did not.

Thank-you for the suggestion. I did disable both anti-virus/malware protection applications - the build still failed to complete. Also these same protection applications are on my notebook and did not require disabling for a successful build. Do you know what Windows 10 build your OS is running? (see if I can rule that out.)

I have two Windows environments, one a MS Surface Laptop 2, the other running in Bootcamp on a Mid-2015 Macbook Pro.

Each environment is running Windows 10 Pro 1903. Both have Visual Studio 2015 installed and with Xojo 2019.R1.1, I can Build & Run the ServerSocketClientTest example as 64-bit successfully in each case.

I hope that helps in some way towards eliminating what the issue is for you. Good luck!

Just out of curiosity, what optimization level are you using and how long did you wait?

Same here. ‘Runs’ for 30 minutes or more and eventually appears to run out of memory.
Thank goodness 32bit is still acceptable on Windows.

Same for me also. I can compile 32bit but 64bit hangs at the linking stage for ever.

Right, but there’s a difference between running out of ram and aborting the build, “hanging” where you seem to be waiting forever and then “crashing” where the IDE just disappears from your screen. That’s what I’m trying to get at here.

  • Out of memory issues typically result in a linking error and your app doesn’t compile.
  • crashing typically is a bug in the linker itself and we’d need a crash log to track it down
  • Hanging is often caused by users setting the optimization level to “Aggressive,” not realizing that this setting can sometimes mean that builds take a long time. For instance, the IDE itself takes two minutes per platform when set to Default on our 12-core builders, but when set to Aggressive, that number shoots up to 25 minutes per platform. It certainly looks like the IDE has hung when this happens.

This is why I’m trying to get to this distinction.

@Greg O’Lone For me its hanging the application. I have choose the Default mode for the 64 bit compile and for the last one hour the app is showing as Linking and doing nothing. I was monitoring the memory usage and its reduced drastically at one point of time to just 9.3 MB, which i have never seen when Xojo is running. But the same source code can compile in a minute when i use my laptop which is also Windows 10. If you need i can give remote access to my PC for checking

Hi Greg,
Optimization Level is Default as per the saved project in examples (didn’t change any setting)

32Gb on Dev 1 PC - I brought up Task Manager and before starting 2019r1.1 I have 15.2Gb available. After load 14.9Gb and no change after opening project. No change during Build - 14.9Gb. For about the first 7 seconds the build seems to run normally, then stops responding. Also, when double checking optimization, I tried building without Hi-DPI support, no change. Have also tried to run at administrator, no change.

The longest I let it sit was 2 hours.

[quote=450566:@Scott Cadillac]I have two Windows environments, one a MS Surface Laptop 2, the other running in Bootcamp on a Mid-2015 Macbook Pro.

Each environment is running Windows 10 Pro 1903. Both have Visual Studio 2015 installed and with Xojo 2019.R1.1, I can Build & Run the ServerSocketClientTest example as 64-bit successfully in each case.

I hope that helps in some way towards eliminating what the issue is for you. Good luck![/quote]

Awesome, good to know. Thanks for the input.

[quote=450606:@Greg O’Lone]Right, but there’s a difference between running out of ram and aborting the build, “hanging” where you seem to be waiting forever and then “crashing” where the IDE just disappears from your screen. That’s what I’m trying to get at here.

  • Out of memory issues typically result in a linking error and your app doesn’t compile.
  • crashing typically is a bug in the linker itself and we’d need a crash log to track it down
  • Hanging is often caused by users setting the optimization level to “Aggressive,” not realizing that this setting can sometimes mean that builds take a long time. For instance, the IDE itself takes two minutes per platform when set to Default on our 12-core builders, but when set to Aggressive, that number shoots up to 25 minutes per platform. It certainly looks like the IDE has hung when this happens.

This is why I’m trying to get to this distinction.[/quote]

Can you explain why the IDE can appear to be hanging? As it seems 64-bit creates sub-processes it doesn’t feel right that the IDE apears hanging almost always (even if it’s a second or more) when building 64-bit on windows (10). I have a fast 6-core AMD Ryzen with lot’s 48GB of memory. Still the Xojo IDE builds do hang the IDE most of the times.

[quote=450589:@Jeff Tullin]Same here. ‘Runs’ for 30 minutes or more and eventually appears to run out of memory.
Thank goodness 32bit is still acceptable on Windows.[/quote]

I’m not seeing that on my end. As noted above (memory stats) I had 14.9Gb free. Let the build run 24 hours now, no change (“Not Responding”) and free memory is 15.0Gb. Total CPU time on Task Manager is 0:00:41, working memory 120,128K and peak memory 393,744K. So no noticeable leaks.

You can give up on that. 24 hrs is too long.

As others have said, make sure your antivirus software isn’t preventing HoudiniAssistant.exe from running or Xojo itself from building.

HoudiniAssistant.exe is my runaway process. At one point I thought it WAS a virus!

is it still chugging away chewing up CPU memory etc ?
seems that’d be a good example to submit to xojo or them to analyze and see if Houdini has hit some infinite loop etc while linking

You mean something that Houdini can’t escape from!!? :slight_smile:

Harry eventually did find something he could not escape from - death

some are not so sure about that even :slight_smile:

[quote=450732:@Greg O’Lone]You can give up on that. 24 hrs is too long.

As others have said, make sure your antivirus software isn’t preventing HoudiniAssistant.exe from running or Xojo itself from building.[/quote]
C:\Program Files\Xojo\Xojo 2019r1.1\Xojo Resources\Win32
How long does Houdini typically live for? I’ve tried build several times watching the task manager and never see it fire up.
Is there a switch to turn on logging, or a log somewhere to see where it is hanging?
I did try building with AntiVirus off, now I’ve added exclusions; but my notebook has the same anti-virus programs and it builds fine.