[SOLVED] not a valid Win32 application

[Okie2003]

I am using VirtualBox (3.2.6 & 3.1.6) on a Linux host (Mepis 8.0, Mint 9 gnome & KDE). I have installed Windows 2000 Pro. I run VB so that I can run two necessary Windows applications: BibleWorks and Libronix Library System. I recently did a minor upgrade in BibleWorks and now when I try to start it I get this error: not a valid Win32 application. I have tried different versions of VB, New and updated installs of Win 2000 and different Linux OSs all with the same result. If I revert to a to an earlier version of BW it will start. Obviously I can just not update, but this is not really a long term solution.

Any ideas or suggestions? It seems to me that the obvious problem is some change in BW code. The programmer of BW is fairly responsive to problems, but not focused on running it is this fashion.

[Perryg]

I don't believe this is a problem with VirtualBox but more of a problem with the updated software and the Windows version that you are running.
I believe I would contact the BW people and pose this question to them.

[Okie2003]

Perryg, thanks for the response. I guess I should have been more clear. I agree with you, but what I am looking for is what to say to them.

It seems to me that the obvious problem is some change in BW code. The programmer of BW is fairly responsive to problems, but not focused on running it is this fashion.

Obviously there is not a problem with the upgrades for those running native Windows installations or for that matter running in wine. I run BW in wine and have not had the problem with the upgrades there. However, wine leaves out some of the functionality, hence a VB install as well. To recap, since BW programmers are not familiar with VB what should I suggest or ask about?

[Perryg]

You can look in the Windows event logs after the program fails and see if it marks it with an error code. Not really sure what else they need to know. As far as it not running and producing the not a Win32 application I do not know any reason that VirtualBox could/would cause this.

[mpack]

now when I try to start it I get this error: not a valid Win32 application

That message usually means that a file which has a .exe extension is not in fact an executable file, e.g. it has been overwritten with (let's say) a renamed text file. You can also get the error message with any file (any extension) if you try to force Windows to execute it though some kind of shell API. You need to look more precisely at the error message, in particular noting the exact name of the file it is complaining about. As Perry said, this problem has nothing whatever to do with VirtualBox.

[Okie2003]

. . . this problem has nothing whatever to do with VirtualBox.

I understand that you probably mean that it is not related to a bug in VB, but it does have something to do with VB in that all these updates must be working with native Windows installs or there would be a major outcry from users. And, as stated above the updates work in wine. So, something was changed in the BW code with the latest series of updates that VB coughs up on.

The error in detail: C\Program Files\BibleWorks 8\BW800.exe is not a valid Win32 application.

I assume that the BW update rewrites part of the original C\Program Files\BibleWorks 8\BW800.exe If I look in C\Program Files\BibleWorks 8\ I can find BW800.exe as well as previous update. If I click on an earlier update like 8.0.016f-BW800lg VB open and runs it fine. However, any updates after 8.0.017* are rejected. I have reinstalled BW and the original C\Program Files\BibleWorks 8\BW800.exe works fine, but when updated to anything after 8.0.017 then no go.

Not having been a Windows user since Win98, where would I find the Windows events logs that Perryg mentioned that might show the information to pinpoint the problem?

Thanks for all the help.

[mpack]

Since my expectation is that the problem is in the install/update program, I wouldn't expect to see anything in a VB or Windows event log: in any case there is no mystery here - your problem is simply that xxx is not a legal Win32 executable, plain and simple. If you look at the file with a hex editor you'll probably find that it consists of all zeroes or readable text. I can't comment on what users on other platforms have or have not reported, I am telling you what (as a programmer myself) is quite plain to me.

In hindsight I was maybe a bit too emphatic in my rejection of the idea that VBox could be at fault. However since VBox knows nothing and cares less about filesystems I do find it hard to believe VB can be at fault with these symptoms: although there have been bugs in recent VB versions to do with lazy writes to virtual drives, I would expect any such bug to produce widespread corruption of the filesystem, not just an inability to execute one file.

Incidentally, please update your profile to indicate your typical host and guest OS.

[Sasquatch]

I would check if the file is the same on the Guest compared to the working one on the Host. That means comparing the checksum of the files.

Another thing you can do, just for testing, is to copy the working updated files/folder to the Guest and start it. If that gives the same error as before, there is something in the virtual environment that isn't calculated in the compilation of BW or Windows just does not understand this update.

[Okie2003]

Since my expectation is that the problem is in the install/update program, I wouldn't expect to see anything in a VB or Windows event log: in any case there is no mystery here - your problem is simply that xxx is not a legal Win32 executable, plain and simple. . . .

Well, unfortunately it does not seem to be that simple. I wish it was. I don't have a hex editor installed in Windows in virtual box or really even know what one is, but I had already done on three or four occasions what Sasquatch suggested. I copied the file from my wine install and this is not just one update, but every update after 8.0.017 began. So for the problem to be a file with all zeros then the file would have had to have been corrupted the 3 or 4 times I copied it from wine and the 6 or 8 times I have downloaded the update. Seems unlikely to me. However, I went to wine again and got the latest update and copied it into VirtualBox c:\Program Files\BibleWorks 8\ I checked the checksum of the file in wine with md5sum in a Linux terminal and downloaded windows-kb841290-x86-enu from the Microsoft website and installed and checked the checksum of the file that I copied to VirtualBox. They were the same. Then I tried to run the file in VirtualBox and got the same error as I had gotten so many times before in more than one install of virtualbox with more than one install of BibleWorks as explained above.

So, it seems to me that something in the coding of the 8.0.017 series of updates is causing VirtualBox to cough. What I need is data or error codes or log info to pass to the BibleWorks programmers. They don't think they have a problem since like I said it is working in Windows (and in wine for that matter). Thanks.

[BillG]

Windows 2000 is pretty old. The real test would be to see if the updates would install on a physical machine running W2k. The developers probably do not test each release on systems before XP.

[mpack]

Well, I think I'm done here. I'll just pass on one debugging tip I've found useful over the years: do not ignore evidence just because it doesn't seem to fit. In this case the evidence is the Windows error message which is telling you clearly that the file in question is not a Win32 executable. I suggest that you find out what a hex editor is, I suggest frHed. Then look at the header of that file, and compare it with the header of Win32 executable, and tell me if they look the same to you. You can do this inside and outside of a VBox guest, to see if VBox affects the outcome (which it would have to do if you are correct and this is a VBox bug). You only need to compare the two headers by eye - if they are different then they will be grossly different - but in fact the format of a valid Win32 executable header is available online if you search for it.

[Sasquatch]

Windows 2000 is pretty old. The real test would be to see if the updates would install on a physical machine running W2k. The developers probably do not test each release on systems before XP.

In addition to this, I would create an XP VM and install BW there including the update and see if you get the same error. If not, then the BW devs made a critical error for Windows 2000 support.

[Okie2003]

. . . which it would have to do if you are correct and this is a VBox bug . .

Thanks for the suggestions. Just a clarification. I thought I had been clear that I do not think this is a VirtualBox bug. I think the coders changed something in the updates to a nonstandard code that VBox rightly rejects and wine and Windows installs over look. I tried to make this clear from the beginning. I was looking for suggestions for where to tell the BibleWorks developers to look that I was looking for. Sorry if I was not clear. If it was a VBox bug would it not be showing up in other applications and in previous BibleWorks updates? I had previously searched this forum thinking along those lines and saw no evidence of it before I posted my first post.

Thanks again. I will try to run down hex editors next week.

Sasquatch, I tend to think you are on the right track. I don't have a legal license for XP, but I might just install it for this text and delete it, but this will have to wait until next week. I know the BibleWorks tries to keep their product usable across old Windows OSs because they know missionaries and pastors often don't have the money to update. I will get on BW forum and see if anyone is still running under Win2000.

Thanks to all for ideas and suggestions. I will follow them up.

[Sasquatch]

If you have an install media of Windows Vista or Windows 7, you can install them without a serial and test it with that. I've also heard that Windows XP with SP3 integrated doesn't require a serial either to complete installation, but you can enter one later. That's something to take into consideration for testing.

[mpack]

I thought I had been clear that I do not think this is a VirtualBox bug. I think the coders changed something in the updates to a nonstandard code that VBox rightly rejects and wine and Windows installs over look. I tried to make this clear from the beginning.

Yes, you said that, but then you went on to assume a state of affairs that could only be accounted for by a VBox bug. Specifically, filesystem corruption. Did you do the check I suggested? It would settle the matter in minutes, and remove the need for speculation.

Incidentally, I don't see how the choice of Win2K, XP, Vista etc can have any bearing on this. The error message is quite clear about what the problem is, and I'm struggling to see why the exact variant of 32bit NT used could create this effect.


A question for Wine experts if you please: if you were to take a Linux executable and run it on Windows then you would get a "Not a Win32 executable" message. What would happen if you ran the same executable under Wine? Wine obviously has the capacity to recognize and run that file, but would it?