Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
I've never seen the term "useful errors" being used. In what way are they useful? You mean they teach you something of great value? Do they happen automatically too?
This error is typically shown when an application cannot find and load a required .dll (what's more, the specific version of that .dll that it was linked with). Not having the required version of the (MS) C++ runtime libs is a common cause. You installed the VC++ 2008 redistributable .dlls, but what version where they and what version does the app require? (IF these are the problematic .dlls)
First thing I'd do after such an error, is check the Windows logs (MyComputer -> right click -> manage -> EventViewer -> System). Open the errors and check the descriptions; search for things like "Dependent Assembly Microsoft.VC90.CRT could not be found" - that way you'll know what .dll it tries to load but fails (in the example error, the proper version of the MSVC++ 2008 runtime .dlls could not be found).
If you have MS Visual Studio installed, you could use the dumpbin tool like this:
dumpbin /dependents Crysis2.exe
to see what .dlls it depends on and tries to load (unfortunately I don't know how to check the exact version of each .dll required - unless the application shipped with a .manifest file, which you can open with a text editor. The app probably has a built-in manifest, and there sure must be ways to see it's info, but I don't know how exactly).
I got it working. I'm not sure what did it. I think it was either the 2005 redist or the 2008 sp1 redist.
I guess you could say ...
crysis averted
But it's really too bad Windows doesn't have a package manager with automatic dependency resolution like Linux. How can MS hope to take a slice of the server, embedded, mobile and supercomputer markets without such basic tools?
The INACCESSIBLE_BOOT_DEVICE bug check frequently occurs because of a boot device failure. During I/O system initialization, the boot device driver might have failed to initialize the boot device (typically a hard disk). File system initialization might have failed because it did not recognize the data on the boot device. Also, repartitioning the system partition or installing a new SCSI adapter or disk controller might induce this error.
This error can also occur because of incompatible disk hardware. If the error occurred at the initial setup of the system, the system might have been installed on an unsupported disk or SCSI controller. Some controllers are supported only by drivers that are in the Windows Driver Library (WDL). (These drivers require the user to do a custom installation.)
The truth is that error reporting on most applications is utterly fucked up.
This is caused by the programmers not giving a shit when they throw exceptions, or when they catch them, or in languages where there are no exceptions, using a single number for the "Error case" and overwriting the output message shared memory (if there is even one, or it was used). Even worse, sometimes the cause of a error is much distant from where the error expresses, so it is useless anyway. Think badly configured config files that lead to runtime errors 6 hours after starting the app or multi-threading corrupting a shared memory area.
There is a precept that is taught at software engineering school about this: "whenever possible, early failure".
The application reports a "general error" because it literally doesn't know wtf went wrong.
Usability is also something alien. Error code 2456. Thank you very much Visual Studio. I guess it was a special kind of hell before the net too.
Then there are the Lovecraftian 20 year old applications where the public interfaces can't be changed because other apps depend on them (exceptions and error codes are part of the public interface).
Lets not speak of when the error is purposefully ignored and silently corrupts data.
The most impressive instance of error reporting i ever saw was a program where all the random sources of input (user key-presses, mouse movements, pseudo random generators) was memorized from the start of the program, whenever a new "value" happened.
Then the exception sent this data along with the user config by the network to a online (automated) bug reporter. It recognized duplicate bug reports (the stack trace would be the same, ie: they originated on the same place). Then the programmer "played back" the bug on their workstations. Not guaranteed to trigger all bugs (since OS libraries versions, cosmic ray shit could be different), but damn impressive.
I'm sure there is some scumbag company that already filled a patent on this, that will be likely be granted by some retard on the US government soon.
We use old system like XP SP3 because it's massively supported not just by official companies but by the userbases. Strike ONE.
Games have less problems with XP SP3 than Vista or Windows7. Not to say they have NO problem, but LESS problem. Strike TWO.
Using new systems risk bugs, damn bugs, and fucking bugs. Why not let they fix them a bit before use. The days we use the newest apps to show we mean business is OVER. that way, nowadays, just show you dont know about reality. STRIKE THREE.
Erm... did you read the bit I put in spoiler tag? Because I did read the documentation... which pretty much restates the error tag itself. Except that the problem had nothing to do with boot devices, or their initialization, or incompatible disk hardware, or SCSI controllers (that was specifically the part where I went WTF? since I don't even HAVE a SCSI controller on this system).
And I think SCO's got the reasons for this type of fuck-up (sadly not limited to Windows or Microsoft) pretty much nailed.
Windows XP is a decade old operating system. Use something more current to run your 2011 game.
