• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 196
  • Last Modified:

Creating x64 compatible builds from Visual Studio


I am developing a Visual Basic application using Visual Studio 2008 / .NET 3.5 on a Win7 x32 machine.

I am experiencing that my application is crashing on x64 installations (win7/8/8.1). I have searched for a solution on how to create an x64 compatible version and I do find a lot of info about this, but it is also quite confusing. Most info I see is related to C# that I am not using.

I do want to avoid a split solution where I must deliver two separate (x32 and x64) versions of my application, because my users would not always be able to make the correct decision on what to use.

Can someone guide me in setting up a simple, yet reliable solution to this problem?
1 Solution
Éric MoreauSenior .Net ConsultantCommented:
why not simply distribute the x86 on the 64-bits platform? Easy and efficient enough for most applications.

and why is your application crashing? any error messages? sometimes it is related to drivers (like odbc, Excel, ...) that are not the same or folders that are different between platforms.
Have you tried to determine why it crashes on a 64-bit system?  32-bit builds are compatible with 64-bit operating systems.  So it is possible that a dependency that your application has may have a 64-bit/32-bit version.  More specifically what is the error you are getting when it crashes?

daghoffAuthor Commented:
Thanks for your feedback. I know I should have supplied more specific info. The last hours I have reinstalled a fresh Win7 x64, installed my program and run it.

The crash does not always show up, but if it does it is usually when I close it. The error message I get is simply that “the program has stopped working”. It offers me the options to close it or search the internet for a solution.

Usually, but not always, I then get a message saying that Windows detected that this program did not run correctly and that compatibility settings has been applied to the program.

And that solves the problem. But I am not happy with this because I would like to prevent the problem from ever occurring in the first place.

I do suspect the crash may have something to do with the program calling Excel and PDFSharp, but I can’t be sure. The problem only shows up when I run on an x64 PC I haven’t used before.

Please see the attachments for problem details.
Any ideas?
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

käµfm³d 👽Commented:
You shouldn't have to compile for a specific architecture unless your application has a reliance on a library that was compiled for a specific architecture (e.g. Oracle's ODP.NET). You should be able to compile as "Any CPU" and have the code run in both places if you're not using any such libraries.

Are you logging errors in your application? Logging would (theoretically) give you more insight into what the problem might be.
daghoffAuthor Commented:
Can you please specify what you mean by logging and how I apply it. I am running my Visual Studio debugs quite standard I believe.

My gut feeling tells me that there is something that the code has been using while the program was running that can’t be released properly when I close the program. It then ends in a hang/crash state and Windows pops up and applies compatibility mode on the program and the problem does not reoccur.

I have pointed to the use of Excel/PDFSharp as the source of the problem, but it is a fact that using these features gives no problems at all. It is only when I close the program the problems show up.
Éric MoreauSenior .Net ConsultantCommented:
I wrote an article on tracing applications a long time ago: http://emoreau.com/Entries/Articles/2003/11/Code-diagnostic-an-article-on-tracing-and-debugging.aspx

Also, are you deploying your application in Debug or in Release mode? I would deploy it after a Debug mode compilation and with the PDB. You might get a little bit more precise exception.

I would also add try...catch to all/most methods called in the application closing to try to find where the exception comes from.
To save you from having to reinstall windows every time you want to reproduce the issue, I think you can turn off compatibility settings by right clicking exe, clicking on properties, going to Compatibility tab and unticking all the tickboxes.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now