We're running our unit tests as a post-build step in our builds. Now I've run into a problem with this on our autobuild machines that automatically pull and build every revision in svn.
The autobuild script pulls down a revision, does some setup and then calls devenv.exe /build on it. This, in turn, will build everything and then try to run the tests. The build gets stuck and never completes.
If you build the solution manually, what happens at the run tests point is a popup dialog box saying the test executable is not a valid Win32 application. I'm assuming the autobuilds somehow get this box as well, but hidden away in a non-interactive session somewhere.
I've had two ideas for a solution this far:
Check in a test-runner application which tries to run the tests and detects the failure. This is undesirable though since this would mean creating this extra kludge of code and adding it to be used only on windows builds etc.
Somehow test if windows is 32-bit or 64-bit in the build scripts (we're running cmake), and simply don't run the tests if they wouldn't work. This is preferable, but requires a way of checking if windows is 32-bit or 64-bit, preferably without having to check in another "test-windows-type" helper tool.
Any further ideas or hints on how to implement suggestion 2 would be much appreciated.
Update: Note here: This is a cross-compile running on a 32-bit machine but compiling a 64-bit exe. If I could just check properties of the compiler, there wouldn't have been a problem. But I'm after properties of the build machine, not of the build itself, which is clearly 64-bit.
Check the %PROCESSOR_ARCHITECTURE% environment variable :
x86 on a 32-bit machine.
AMD64 on a 64-bit machine (cf. here).
You should be able to check the CMake generator which I think is different for 32/64 bit windows.
Not an answer to the the specific question you asked, but you should perhaps consider building your app on an x64 machine, which could run 32-bits tests as well as 64-bits tests...
You can check the CMAKE_SIZEOF_VOID_P variable in your build script to detect the type. See documentation here. Then you can skip running the tests if this variable is 32.
Update: Sorry I overlooked your real issue. I think the best approach may be to apply a try-run test and use the RUN_RESULT_VAR to determine if the app ran successfully.
I found out one way to identify if the system is 64-bit or not, which should be possible to access from cmake. It feels as a rather ugly hack though that could break on any random version of windows, so I'd still rather find another way.
The %ProgramFiles(x86)% environment variable only exists in 64bit OS versions.
Related
I have a 32-bit application and I have a problem with it on Windows 7 x64. I'm loading a DLL. LoadLibraryW succeeds and the subsequent call to GetProcAddress fails with the error code 127 ("procedure not found" or something like that).
The funny part is that I know for a fact the function is exported by the DLL. I made no typos in the GetProcAddress call. I can see the function with Depends.exe and DllExp.exe. The exact same application binary successfully loads the function from the exact same DLL on Windows 10 x64, but not on Windows 7 x64.
Some more details: the library is dbghelp.dll and the "missing" function is MiniDumpWriteDump.
And the fun bit: dbghelp.dll provides API for inspecting the modules loaded into the process and for enumerating functions exported by those modules. So, first I took the HMODULE for this problematic dbghelp.dll and ran
auto ptrSymInitialize = (decltype(&SymInitialize))GetProcAddress(hDbgHelpDll, "SymInitialize");
It worked, this function did load! Then I loaded SymEnumSymbols, written the enumerator callback and finally ran the following to enumerate all the functions in this very `dbghelp.dll":
ptrSymEnum(GetCurrentProcess(), 0, "dbghelp*!*", &Enumerator, nullptr);
And what do you know, MiniDumpWriteDump is, in fact, listed there. Go figure.
Thoughts?
I can see your intent is to use MiniDumpWriteDump. We also make minidumps in our product, and I'm the one to support this.
I would suggest against using dbghelp.dll supplied with OS. First, they tend to be outdated and not support the latest minidump capabilities, which you would want to have. Second, they have proven to be rather unreliable. I believe they simply lack too many bugfixes.
What I found to work quite well is to take dbghelp.dll from Debugging Tools for Windows package (currently part of Windows SDK) and ship it along with our product. This way, I can be sure minidumps will have all the latest features and it works reliably on all OS. It has been some 8 years now, with OS ranging from WinXP to Win10, and I didn't have any issues.
I'm not exactly sure which version of SDK I used to extract the currently used dbghelp.dll, probably it was Win7 SDK. I simply didn't have a reason to update since then. However, we do use Debugging Tools for Windows package from Win10 SDK on Win7 without any issues, so I guess you can use Win10 version as well.
that's exactly what I've been doing, and I didn't bring dbgcore.dll
This was just a plain bad idea. Microsoft makes no effort to make the DLLs that are included with the OS to be backwards compatible. They don't have to. In their implementation, only the interface needs to be compatible. They do take advantage of new capabilities or design changes to improve the implementation.
Like you saw here, a side-effect of the MinWin project. There is no reasonable guess where that ended, if it happens to work now on the Win7 machine then you got lucky. Maybe you won't be so lucky on a Win7 machine without SP1, maybe some minwin glue DLLs are missing on a clean install, maybe the minidump itself is affected negatively some way. Impossible to predict.
So never do this. Afaik you should not be doing this at all, a Win7 machine already has dbghelp.dll available. Not 100% sure, it has been too long and Win7 is rapidly turning into the new XP. If you find it to be necessary then always use the redistributable version. Included with the SDK's Debugging Tools for Windows. Copy it into the same folder as the EXE that needs it so you don't mess up a machine.
I need to use the debug command in Windows 64x for learning purposes. When I type the command debug in the cmd, I get the following message:
'debug' is not recognized as an internal or external command,
operable program or batch file.
As I understand from some previous posts that debug does not work in 64x systems. Is there any work around for this issue?
EDIT:
I am trying to write assembly code for learning. I am not allowed to use any other option for writing assembly code. I have to use DEBUG.
debug.exe is not available in any of the 64 bit windows versions. What are you trying to accomplish? One option for you may be gnu debug - http://www.sourceware.org/gdb/
I know this is an ancient thread, but others might have the same question.
In general to use legacy software, the CLEANEST way to do it is to use the build in Hyper-V. And then have PC-DOS 3.30 (or any suitable 16 or 32 bit OS) on that.
Make sure to use a DYNAMIC disk (vhdx). This allows the disk to be mounted in Windows simply by clicking the vhdx (when not in use by Hyper-V - no sharing), so this allows for simple transfers, without complex net-setup.
There are other alternatives such as DOSBOX, though to my experience their emulation have some bugs (e.g. on the ancient FCB-system - older than file-handles)
I know it's a very long answer, but I just saw your post now. Use the vDosPlus (http://www.vdosplus.org/) or vDos (https://www.vdos.info/) software to run 16-bit (MS-DOS) programs on Windows 64-bit.
I'd like conditional compilation based on whether the compiling machine is running Windows 7 SP1 or not.
We have a workaround for http://support.microsoft.com/kb/2517589 but I don't want to check the code in unless it is guarded by an #ifdef _WIN7_SP1 otherwise the other devs won't be able to compile it on their non win7-sp1 machines.
I've had a bit of a google but couldn't find anything useful.
You don't. Things in the environment of the build machine generally don't pollute compilation like that. (Imagine if that happened and what effects it would cause on reproducibility of builds.)
If you really need to, I'd instead have your build system (make, Visual Studio, whatever) execute a program that checks the current Windows version and fails as necessary (or possibly your build system can determine this already). Based on that, you then could conditionally make own WIN7_SP1 definition via a command-line argument to your compiler.
I really hope someone can be of help to me because this problem has me totally stuck and frustrated.
Yesterday I installed a fresh and shiney new Windows 7 x64 onto a development box.
I got VS2008 installed, Tortoise SVN, did a checkout, compiled my currently project, all fine and dandy.
But when I go to run (either F5 in VS or just running the exe from the shell) I get a dialog box that looks like this:
(source: aliparr.net)
So I fiddle around and can't see an obvious problem. I bust out depends.exe, thinking maybe there's a dll missing, and I get this:
(source: aliparr.net)
So I play, finding different versions of gpsvc.dll and ishims.dll and putting them in with the .exe, No luck.
If I do a profile in depends (which follows the Output window of vs), I get this:
..
Loaded "c:\windows\syswow64\ADVAPI32.DLL" at address 0x75F20000 by thread 1. Successfully hooked module.
Loaded "c:\windows\syswow64\LPK.DLL" at address 0x76B20000 by thread 1. Successfully hooked module.
Loaded "c:\windows\syswow64\USP10.DLL" at address 0x761C0000 by thread 1. Successfully hooked module.
Loaded "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\MSVCR90.DLL" at address 0x70570000 by thread 1. Successfully hooked module.
Loaded "c:\users\ali\desktop\repository\development\trunk\spree\bin\debug\OPENLDAP.DLL" at address 0x001E0000 by thread 1. Successfully hooked module.
Exited "c:\users\ali\desktop\repository\development\trunk\spree\bin\debug\SPREE.EXE" (process 0x5D4) with code -1073741701 (0xC000007B) by thread 1.
So it seems openldap.dll is the last thing to get loaded before it all goes wrong. I require this dll because I use cURL within the application to do a little JSON communicating...
I've tried playing with moving files and trying differing dlls, but honestly I'm acting a little blind here. Can someone please help or point me in the right direction?
It should be noted these dlls and setup work fine in Windows Vista x64 and x86 - is this a Windows 7 thing?
Massive thanks in advance, I might still have some hair left after this is done.
Edit
I've now realised curl.exe dies in exactly the same way with openldap.dll - I guess some windows 7 issue?
Can you/does anyone have a curl without the dependency on openldap? Is there another lightweight C/C++ library out there that'll let me fetch a document over http and do the odd http POST ?
Thanks
I had a very similar problem myself: I was developing a C program (using the MinGW gcc compiler) which used the curl library to do http GET operations. I tested it on Windows XP (32-bit) and Windows 7 (64-bit). My program was working in Windows XP, but in Windows 7 it crashed with the same 0xc000007b error message as the OP got.
I used Dependency Walker on a down-stripped program (with only one call to the curl library:curl_easy_init()). I essentially got the same log as yours, with OPENLDAP.DLL as the last successfully loaded module before the crash.
However, it seems my program crashed upon loading LIBSASL.DLL (which was the next module loaded according to the log from Dependency Walker run on Windows XP).
When looking again in the log from Dependency Walker on Windows 7, LIBSASL.DLL indeed shows up a x64 module. I managed to get my program to run by copying a 32-bit version of the DLL file from another application on my harddisk to my program's directory.
Hopefully this will work for other people having similar problems (also for the OP if the problem still wasn't resolved after these years). If copying a 32-bit version of LIBSADL.DLL to your program's directory doesn't help, another module might cause the crash. Run Dependency Walker on both the 32- and 64-bit systems and look up the module name from the log of the successful run.
I cannot answer your questions completely, I've compiled libcurl on Windows 7 Professional x64 and I don't have any issues. Although I haven't compiled it with OpenLDAP support so I suppose that's where the issue lies.
Regarding the IEShims.dll, Dependency Walker usually reports this as a missing module. Can't remember the exact reason but it was something about loading it dynamically when it's not found in %Path%.
If you however need to debug this and are on Windows 7 then try doing a hard link from %ProgramFiles%\Internet Explorer\IEShims.dll to %windir%.
Although, I see on the screen dump that it sure looks like Spree.exe isn't loaded as a x64 binary, which could very well be it. There's a difference in loading exported functions and piping or exec() a binary, the first mentioned requires that the architecture is the same for both the importer and exporter.
I've also found that mine is trying to load a 64 bit version of LIBSASL.DLL - the one that came with my 64 bit Tortoise distribution. I also only need curl for pulling a bit of JSON data. I think the best solution is going to be to rebuild libcurl from source and exclude the LDAP since I don't need it anyway.
Similar issue here. DLL dependents GPSVC.DLL and MSVCR90.DLL.
I managed to get rid of IESHIMS.dll by setting my environment variables path to C:\Program Files (x86)\Internet Explorer. Surely that shouldn't need to be done!
Is there a fix to this yet?
libsasl requires ieshims.dll, if you don't have sasl support in openldap, then ieshims.dll won't be required.
If you use windows x64 you have to copy your dll to c:/windows/SysWoW64. I have had the same problem when i wanted use pthreads in windows os 8. When I was copied pthreads dll to SysWow64 the program was run sucessfully.
I'd like to configure visual studio 2005 to copy .dll's based on whether the OS is 64-bit or 32-bit during a build.
I do not want to specify what the platform target is.
My first attempt was to use a batch file to lookup the Windows version, but some 32-bit and 64-bit versions of Windows share the same version number.
Anyone know of any way to check this?
Thanks!
You should be able to read the environment variable %PROCESSOR_ARCHITECTURE%. Here is some great information on it.
http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bitness.aspx
Check out isWow64, I think that shopuld give you what you are after.
Determines whether the specified process is running under WOW64.
Jon's link is a total hack because it relies upon no new processor architectures being added.
See: http://support.microsoft.com/kb/556009 for the "official" batch file method.