Windows binary won't work on another box.

Windows binary won't work on another box.

I built SETI@home on my Windows xp sp2 English box (P4 2.8G HT) and confirmed it worked as expected. It's compiled with /MD options, and linked with svml_dispmt.lib,libmmds.lib,libircmt.lib in addition to the original VS .NET 2003 libraries. No fatal error was displayed. This binary is compiled and linked to run as fast as possible; ie, with "/fast /G7 /QxP /QaxP" options. Yes, redundant, but I hope it doesn't harm.

I have another machine running WIndows xp sp2 Japanese (P4 2.4G single thread.) So I tried to run that binary on this box also, but it wouldn't work on this box. No error message is displayed. What's wrong with this? The only differences are (maybe) English version vs. Japanese version, and the type of cpu, P4 HT vs. P4 single-thread.

Both boxes are fully updated with Windows update.

PS: I've compiled another program boinc, which was linked with libmmds.lib and libircmt.lib, and it works fine on either box.

Message Edited by maverick6664 on 05-05-2005 08:15 PM

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

sorry...this doesn't seem to be the problem of the compiler; it looks like a problem of that computer. I will do clean install and try again...

Again, Intel's compiler is excellent (as well as on the Linux.)

Thank you!!

But, now I wonder why this happens. My problematic machine doesn't have other problems except that vnc connection is a bit slow... Does it matter?


There's really not enough information here to know for sure. For the situation where the exe fails, have you executed it in the debugger to see how it is failing? Is the application even loading? Is it crashing?

Running in the debugger should provide some clue as to how it is failing. What's the backtrace look like in the debugger?

You may then step through the debugger on both machines and see where the behavior deviates.


sorry for not mentioning the details, but Iound the solution. It's very simple.

My second machine's Pentium4 doesn't support SSE3, although I used /fast option which implies /QaxP(SSE3 enabled). I didn't know Windows command line mode didn't give any error message (like segfault/exception fault in Linux) when an inappropriate instruction is executed. My first machine (dual boot of Linux/Windows) has P4 supporting SSE3, so it doesn't have any problem with my binary.

I used Intel processor identification utility to find it. I am not familiar with debugger on Windows yet (only gdb on Linux) and the second machine runs only Windows....


Message Edited by maverick6664 on 05-06-2005 10:21 PM


I'm glad that you found the issue although I'm surprised that you didn't get an illegal instruction exception on the machine without SSE3 support.



Leave a Comment

Please sign in to add a comment. Not a member? Join today