Hard Light Productions Forums
General FreeSpace => FreeSpace & FreeSpace Open Support => Topic started by: Kie99 on July 08, 2010, 02:28:33 pm
-
(http://i28.tinypic.com/mtlcsm.png)
Get that on the load-up of Launcher and FSO. Using 7, but it happened on my old computer on Vista as well. Did a search, couldn't find anything.
-
Windows error. There are many probable causes, use the google for great justice.
-
i'v been getting the same in windows XP for the last few weeks, if you go through your registry deleting all references to the game (i used the search Freespace with not having the original) then run the game it fixes it for the current boot but when you restart the computer you start getting it again.
i get the issue when starting, launcher, running the game through the launcher and starting FRED
using
launcher 5.5f
fs2_open_3_6_12_RC3r_INF_SSE.exe (both the r and d versions of the exe)
fred2_open_3_6_12_RC3d_INF_SSE.exe
[attachment deleted by ninja]
-
There's another thread about this somewhere. You can get that error from a variety of reasons. Someone got it because of a card reader in their computer. I got it once for some reason (again the card reader, or the printer, I dunno).
Edit: http://www.hard-light.net/forums/index.php?topic=68223.0
-
Yeah as said in the other thread, something to do with the memory card reader, it can safely be ignored. Click continue and everything still works fine, just an annoying nag.
-
Another solution by someone was to update their onboard RAID drivers. Don't even have to be using a RAID setup.
-
im not sure my board even supports RAID lol
goin to have a look though
edit:
I stand corrected it does
-
Another solution by someone was to update their onboard RAID drivers. Don't even have to be using a RAID setup.
Yeah, that was me. I installed some VIA raid drivers and the problem seemed to disappear. Although now my card reader decides when it wants to work or not! :nervous:
I then installed Vista and haven't had the problem since.
-
Mine's been doing that too ever since upgrading to launcher 5.5e and 3.6.12 RC2. Prior to that I hadn't updated in forever and was running an old nightly build of 3.6.10, and never had the problem...
-
Seems wierd that FSO is the only thing that seems to trigger it? :wtf: :nervous:
-
Can you try these two builds:
rev 5698 (http://www.hard-light.net/forums/index.php?topic=66853.0)
rev 5692 (http://www.hard-light.net/forums/index.php?topic=66807.0)
For me, the issue turned up in 5698, and was not in 5692.
However, I do not see the issue if I compile FS2 Open myself - this is quite strange!
I've currently suppressed the error via the Registry as it was annoying me too much, and my current PC is too slow to compile from source in a sensible length of time.
- Didn't recheck since. Too busy at work...
-
*Sigh*
I should just close this.
Because, as I said before, it's NOT AN ISSUE WITH FS2_OPEN.
-
I've only ever seen this on Windows 7, but the game runs fine if you hit Cancel, so...
-
Not just a Windows 7-specific symptom, I've seen it occur on Vista too - with other apps, mind you. Used to see this come up all the time in particular with the Zune software.
As stated by The E, this definitely isn't an FS2_Open-specific problem, but is more of a general Windows anomaly. Google searches will lead to hits such as this page (http://stevegilham.blogspot.com/2010/02/no-disk-deviceharddisk3dr3.html) with tips on isolating which exact storage device is the offending one (i.e. checking disk management - the fix outlined here was the same way I fixed it with the Zune software as well).
-
*Sigh*
I should just close this.
Because, as I said before, it's NOT AN ISSUE WITH FS2_OPEN.
Please, calm down and read the bug reports again.
If a problem is seen in Build X but not Build Y, then there is definitely an issue with the differences between those two builds.
That is elementary and always true.
(If it's seen after Date X and not before, then it's a change in the machine.)
If you don't want or have time to investigate this yourself, that's absolutely fine - it's a volunteer project and nobody has to do anything they don't want to.
But please - don't deny a bug could exist.
I stopped testing because you were so vehement, and only one other user was affected. So I suppressed the error and gave up.
Going back to that nightly build thread, chief1983 found a possible suspect.
I didn't see the error if I build from source, so I can't test that fix.
How about we see if other users have the possible bug appear across that boundary?
That happens for bugs that are almost certainly with graphics card drivers, so let's allow Windows and the build chain the same respect, eh?
Finally, the 'solutions' provided on the various sites are only to tell Windows not to show the dialog (or 'missing DLL' dialogs either - this is dangerous)
- Just because a given error message can be suppressed via the Registry does not make it a 'general Windows anomaly' - the error is still there!
I'm going to drop the subject again after this post, as I'm replacing this machine next week and don't feel like having another argument.
-
Please, calm down and read the bug reports again.
If a problem is seen in Build X but not Build Y, then there is definitely an issue with the differences between those two builds.
That is elementary and always true.
(If it's seen after Date X and not before, then it's a change in the machine.)
Except that there are no appreciable differences in the code between those builds. There are no commits there that would seem to have an effect on this.
If you don't want or have time to investigate this yourself, that's absolutely fine - it's a volunteer project and nobody has to do anything they don't want to.
But please - don't deny a bug could exist.
I stopped testing because you were so vehement, and only one other user was affected. So I suppressed the error and gave up.
I don't deny there's a bug here. But it's not a bug in FS2_Open (or if it is, the steps to reproduce it are very, very arcane). All indications point towards it being a Windows bug. So I'll keep saying that until someone with way more time on his hands proves me wrong.
Going back to that nightly build thread, chief1983 found a possible suspect.
Which nightly build thread?
I didn't see the error if I build from source, so I can't test that fix.
And that, my dear Tomo, is the most conclusive argument for it not being a FS2_Open code bug. Because if it was a code bug, you'd see it appear regardless of whether or not you made the build, or you're using one of the precompiled ones. Now, there could be an issue regarding the compilation process itself, so any information you can give us regarding your IDE setup would help.
In addition, have you tried running the game with a debugger attached?
-
I'm not denying the fact that this is a windows bug, just pointing out the fact that we all experience this when starting FSO, no other program generates this warning, just FSO!
-
I'm not denying the fact that this is a windows bug, just pointing out the fact that we all experience this when starting FSO, no other program generates this warning, just FSO!
But its not just FSO that has this problem. When you google the error message, the posts that are found by Google are about a very wide variety of applications (none of which are any relation to FSO) that all have generated this error at some point.
It just so happens that only FSO generates the error for you. Personally, I have never run into this problem while using FSO or the launcher. The only time have have hit this error is actually with Photoshop (of all things) on Windows XP (which was about 5 years ago) when a USB card reader for MemoryStick was plugged into the computer.
Also, if you look at older posts in this support forum, you will find that this comes up very regularly. The only common theme is that it comes up when running the launcher and/or FSO, which is no surprise as this is a FSO support board. The only common solution? What exactly has been said here, find the device that is causing this issue (usably a built in card reader) and the remove any card from the device or update the drivers for the device. Occasionally, the issue has been caused by an on-board RAID controller (you don't necessarily need to be actually using it) and the solution is updating the drivers for it.
-
The reason I'm annoyed is that you jumped on the thread and told someone not to try a perfectly valid fault-finding step.
Why not let the OP try those two builds and see what the results are?
Going back to that nightly build thread, chief1983 found a possible suspect.
Which nightly build thread?
This one:
http://www.hard-light.net/forums/index.php?topic=66853.0
I didn't see the error if I build from source, so I can't test that fix.
And that, my dear Tomo, is the most conclusive argument for it not being a FS2_Open code bug. Because if it was a code bug, you'd see it appear regardless of whether or not you made the build, or you're using one of the precompiled ones. Now, there could be an issue regarding the compilation process itself, so any information you can give us regarding your IDE setup would help.
Sorry, but that's an incorrect statement.
What that symptom shows is that the problem is triggered by a difference between build and running machines.
Exactly what those differences are is unknown - I'd guess that it's something to do with the filesystem, probably removable drives, but can't be sure of that.
- As another example of such an issue, if you compile FSO on a machine with new MSVC dlls then try to run it on a machine with significantly older MSVC dlls, then you will also have a problem.
Yet compiling on the old machine will work fine.
Consider the following facts:
A) The issue is seen on certain machines when running Build 5698 from Nightly and all builds since.
B) The issue is not seen on those exact same machines when running Build 5692 from Nightly and older.
C) The configuration of the running machine is identical when either build is run - the builds can be run in either order immediately after each other without changes to behaviour.
There are two (and only two) possible explanations for this:
1) There is a code change between those versions that causes the error for certain configurations.
2) There is a change in the nightly-build machine that causes the error for certain configurations in all builds after a certain date.
This could be determined by having the machine used to build those two nightlies rebuild them, then test these new builds on one or more machines known to display the fault.
- If the fault is in both on rebuild, then it's a machine config. If the fault stays in 5698 and is still not in 5692, then it's code.
In addition, have you tried running the game with a debugger attached?
Unfortunately I don't have one available.
Looking at the diffs, there is a significant change between 5692 and 2698 that could be related - there are a *lot* of changes to mspdb_callstack, and the initialise method for that is called just before game_main - and it wasn't in 5692.
(Edited to fix my quote mashup)
-
Umm.
If you can make your own builds, you should have access to a debugger. Even the one in Visual C Express should suffice to get a fix on this.
Also, I can pretty much guarantee that there was no difference in the build environment for those nightlies; both were made using MS Visual Studio 2008 on a Win XP machine (if I remember chief's build setup correctly).
-
Hah. You know what? I might have to take back my earlier sentiments - maybe there is something specific to the launcher app or FSO causing this.
Don't burn me at the stake yet - I'm only changing my stance because I actually have something vaguely resembling tangible proof. Up until this point I've always had some kind of disc in my system's drives, but today ended up removing all that media. When I launched the game via launcher.exe, Windows suddenly (before the launcher even fully loaded) threw a generic "There is no disk in the drive. Please insert a disk into drive G:" (one of my DVD drives) with "fs2_open_3_6_12_RC4r_INF_SSE2.ex - No Disk" in the title bar. I repro'd the issue with Process Monitor running, looked for all instances of G:\, and found this:
(http://illuminatihq.net/FSOFileNotFound.PNG)
Interesting, no? In a way this might also explain why another person was reporting the error didn't happen if they did their own build from source - seems like this might be a legacy of the configured dev environment from whoever built this particular exe, though I'm hardly a Visual Studio expert.
The error of course is otherwise utterly benign and I can skip it and launch the game with no impact - I expect putting a disc back in my drive will of course make it go away again too (the "not found" failure will occur gracefully rather than making Windows freak out about non-existent media). Just wanted to throw my two cents in here anyways that the problem might have something to do with the way the latest builds were put together after all, since now there's actually something in the way of tangible evidence to present to this end.
-
That makes sense - I also have a drive G with removable media (Compact Flash card reader)
Also explains why it's not seen by very many people, because you'll only see it if a *removable* Drive G exists - otherwise, Windows comes back with PATH NOT FOUND instead.
- Will try remapping that drive letter tonight to see what difference it makes.
This does prove that there's something screwy in the PDB stuff.
Anyway:
The dialog pops up when you start the Launcher because the first thing the Launcher does is to run FS2-Open to get the supported and recommended command line (and other) options. It also does that whenever you select a new FS2-Open executable.
-
Well, according to this: http://msdn.microsoft.com/en-us/library/yd4f8bd1(v=VS.71).aspx that's just what it is designed to do, and there's nothing we can really do about it (except maybe ask chief to move the drive location to somewhere seldom used, like V: or W:). Short version: PDB debugging embeds the absolute path to the pdb in question in the exe (and no, there is no way to adjust that behaviour), and the search path for the pdbs calls that location first, then the current exe path.
-
Since pdb's are unnecessary with R-builds as far as I know, perhaps chief should remove R-build pdb's from his script. That alone would eliminate the problem for most people for most of the time. Even if the problem still occurs with D-builds, it's a minor annoyance. Even so, pdb-extensions for D-builds could be renamed until you need them.
Removing R-build pdb's would also cut 7z-archive size from 14.0 MB to 11.5 MB if he would use LZMA Ultra compression. He doesn't use Ultra though so archives are larger. Still, roughly 20% size reduction in archive sizes by just removing R-build pdb's is useful. Combine that with highest compression level and chief can shrink nightlies down to 11.5 MB. I hope that'd be enough to get him into including SSE2 debug builds in SSE2 archives, because downloading both SSE and SSE2 nightlies for the debugs is a mild annoyance.
-
Since pdb's are unnecessary with R-builds as far as I know, perhaps chief should remove R-build pdb's from his script. That alone would eliminate the problem for most people for most of the time. Even if the problem still occurs with D-builds, it's a minor annoyance. Even so, pdb-extensions for D-builds could be renamed until you need them.
Nope, it wouldn't. The problem isn't the presence of pdbs, it's the way how pdbs are used by Windows. Whether or not you have pdbs is completely irrelevant; the simple fact that these builds were made using pdb debugging information is enough to trigger this.
Removing R-build pdb's would also cut 7z-archive size from 14.0 MB to 11.5 MB if he would use LZMA Ultra compression. He doesn't use Ultra though so archives are larger. Still, roughly 20% size reduction in archive sizes by just removing R-build pdb's is useful. Combine that with highest compression level and chief can shrink nightlies down to 11.5 MB. I hope that'd be enough to get him into including SSE2 debug builds in SSE2 archives, because downloading both SSE and SSE2 nightlies for the debugs is a mild annoyance.
True, but beside the point.
-
The problem isn't the presence of pdbs, it's the way how pdbs are used by Windows. Whether or not you have pdbs is completely irrelevant; the simple fact that these builds were made using pdb debugging information is enough to trigger this.
Do R-builds need to be made using pdb debugging information in the first place? It's just doesn't seem useful.
-
I guess not. Looking at the project configuration, it seems that the release exes are built with the Linker /DEBUG switch on, which seems unnecessary.
-
Probably because the Preprocessor Definitions was supposed to house a PDB_DEBUGGING option and they are not.
I'm fine with removing the linker setting so long as it is tested. And it's probably high time that the project settings get re-evaluated anyway.