We have an application built with Visual C++ 2005, and one customer has reported that he's getting this runtime error:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: [path to our application]
R6002
- floating point support not loaded
According to Microsoft (on this page), the possible reasons for this are:
the machine does not have an FPU (not in this case: the customer has an Intel Core 2 Duo CPU and I haven't seen a machine without FPU since the 486SX)
printf or scanf is used with a floating-point format specification but there are no FP variables in the program (our app contains FP variables but I'm pretty sure we never use printf or scanf with FP formats)
Something to do with FORTRAN (no FORTRAN code in our app)
Also, the error is occurring while they're using our application (specifically, just after they select a file to be processed), not when the application starts up.
I realise this is a long shot, but has anyone seen anything like this anywhere before? Google was pretty unhelpful (there were lots of unsupported claims that it was a symptom of some kind of virus infection but very little apart from that).
Any suggestions gratefully received :-)
Are you linking a static version of the CRT? If so, you need to have floating point variables in the binary that calls printf(). And these variables have to be really used (i.e not optimized out by the comppiler).
Another possibility is a race between the CRT initialization and the code that uses these FP routines, but that would be hard to produce.
R6002 can be caused by printf trying to print a string that contains a percent-sign.
Most likely root cause of such printf failure is a program that manipulates arbitrary files and prints their names. Amazing to me, there really ARE people who put percent-signs in file names! (Yes, I realize that is technically legal.)
printf("%f\n", (float)rand() / RAND_MAX);
I experienced the same runtime error in a program compiled with VS2010 command line cl.
The reported error occurred without the (float) cast and disappeared when I added it.
Related
I have a standard VB 6 exe (mailviewer).
This program has a "link" to a cobol DLL:
Declare Sub InkMvwMail Lib "inkvwm" Alias "INKMVWMAIL" ...
When starting the normal exe from windows,
EVERYTHING WORKS FINE,
but when I want to debug the call to the cobol DLL entry point in Visual Studio 6.0 (SP6) (on windows xp), I get
"Error 49, Bad Calling Convention"
Thanks for any help in advance
Wolfgang
EVERYTHING WORKS FINE,
No, it only looks that way. Everything is not fine, that Cobol function was designed to be called from a C program. It has the wrong calling convention, cdecl instead of stdcall. The stack imbalance that's caused by this can cause extremely hard to diagnose runtime failure, like local variables mysteriously having the wrong value and includes the hard crash for which this site is named.
When you run from the IDE, the debugger performs an extra check to verify that the stack pointer is properly restored across the function call. It is not, thus generating the error 49 diagnostic.
You'll need to follow the guidance in this KB article. It cannot be solved in VB6, this requires writing a little helper function in another language that can make cdecl calls, like C or C++. The KB article shows what such a function could look like, although they intentionally gave it the wrong convention to demonstrate the problem.
Answering another question about how const string data was stored in an executable a question occured: Why are run time error messages stored in the executable rather than generated by the OS?
!This program cannot be run in DOS mode.
Seems reasonable, DOS can't be expected to detect a newer Windows app and generate an appropriate error message. Some others about stack frame corrupted might also occur when your program is in a state where it can't reliably communicate with an OS function
But some make no sense:
- Attempt to use MSIL code from this assembly during native code initialization...etc..
If I was trying to call a .Net assembly (which I don't - this is pure C++ code) surely the .Net or OS runtime could manage to generate the error message itself.
And the file system error messages are also in the exe. Surely I want these errors to be generated by the OS at run time - if the app is being run on a non-english version of Windows don't I want system errors to reflect that language rather than the one I used to compile it?
Just a Friday afternoon sort of question but there doesn't seem to be anything about it on Raymond Chen's site
The examples I know of are stubs that are placed specifically because there isn't a good way for the OS or some runtime to produce the error. Also, they are fundamental problems with the implementation, not the types of errors a user should ever see.
The DOS one is a perfect example. There's no way for DOS to recognize a Windows program and produce a reasonable error, so the stub code is included in Windows programs.
Your MSIL one is very similar. How can the runtime produce this error if the runtime isn't actually loaded (because the program is still initializing)?
Another example I can think of are "Pure virtual function called" in C++ programs. The abstract base class vtables are filled with stubs that emit this message. I suppose they could be stubs that make an OS call to produce the same message, but that seems like overkill for something that's never supposed to happen.
There's a similar problem if you try to call into the floating point library from a native C or C++ program that isn't actually linked against the floating point library. This is essentially a floating-point implementation detail of the language runtime library (in cooperation with the compiler and the linker). It's not an OS-level issue (in the sense that something like "file not found" is).
It's so you can globalise your application.
E.g
Ivan can have the error messages in Russian even though it's running on a French OS.
I'm guessing this is code pulled in by the CRT, try compiling a test application that does not link with the default libraries and use mainCRTstartup as the entry point, then the only string should be the error message in the DOS stub.
I'm new to Win environment, trying to write code which use win kernel API but on Ubuntu 10.04 ... using mingw32 (more specifically, i586-mingw32msvc)
My code:
#include<ddk/winddk.h>
int main()
{
return 0;
}
But I'm getting to many errors with ddk/winddk.h header:
Compiling as: i586-mingw32msvc-gcc WaitForSingleObj_2.c
All errors are like this:
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/ddk/winddk.h:9208: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'NTSTATUS'
Am I missing something for this? As I tried to compile with headers iostream and windows.h, that works fine.
EDIT:
#include<ntdef.h>
#include<ddk/ntddk.h>
#include<ddk/winddk.h>
#include<ddk/ntddndis.h>
int main()
{
KTIMER *timer;
KeInitializeTimer(timer);
return 0;
}
till KTIMER its fine, now new error:
/tmp/cc0epAQA.o:WaitForSingleObj_2.c:(.text+0x1d): undefined reference to `_imp_KeInitializeTimer#4'
collect2: ld returned 1 exit status
Can anyone tell me, now which header file to include plz?
Edit: [As others commented already, and I experienced(!) PLEASE try to avoid using other platform for Windonws Kernel development]
I switched to Visual C++ Express, downloaded WDK, given additional include path from Project Property->c/c++ .. ->Additional Include directory (C:\WinDDK\7600.16385.1\inc\ddk;C:\WinDDK\7600.16385.1\inc\api;)
BUT (I hate this but!) I'm getting many compiling error like
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(543): error C2143: syntax error : missing ')' before 'const'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(543): error C2143: syntax error : missing '{' before 'const'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(543): error C2059: syntax error : ','
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(543): error C2059: syntax error : ')'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(550): error C2143: syntax error : missing ')' before 'const'
My Code:
#include <wdm.h>
int mian()
{
/*
* PKTIMER Timer;
*/
}
If anyone has idea please help!
Are you sure that ntdef.h is being included, either explicitly or by certain #define values being set? That's the header that defines NTSTATUS and that error message is the one gcc normally spits out when a symbol/type has not been defined.
In any case, developing Windows device drivers using a non-MS compiler will almost certainly have more problems than with Microsoft's own toolchain.
Dhara Darji, you still haven't quite understood what I was writing before. It is not merely the toolchain that is important. As I pointed out you will not be able to get your driver certified (although you might get it - or the .cat - cross-signed). I stand by every word from my comment:
Well, you should know your tools. Developing for KM on Windows (as for
many other platforms) is no kid's play. If your UM app crashes, the
app dies. If your driver crashes, the system dies. Please reconsider
using unsupported tools for creating Windows KM drivers. Not to
mention that your idea of drivers seems to be non-existent from the
code snippet above. It is completely different from UM and should not
be taken lightly.
Even now in your last attempt, except for the misspelled main (as mian), you don't seem to know that a driver requires an entry point called DriverEntry and that this takes parameters completely different from a classic main.
As I pointed out before, you are mixing user mode (UM) and kernel mode (KM) concepts. This will simply not work. There are no ifs and buts. A few years ago people even argued that C++ wasn't the right language to write KM code. Mostly because of the semantics of new and the implications with paged and nonpaged pool. These days C++ is accepted for its type-checking. There we have the next thing "pool", what's that? You have to learn at least the basics of the Windows internals, and I'm afraid that at least the edition of "Windows ???? Internals" I read back in the days didn't quite cut it. You'll want to get a proper book about drivers, such as Oney's "Programming the Microsoft Windows Driver Model" or a number of the books - including old titles - from the guys at OSR. Even very old books from NT4 times still contain a lot of valuable information, even though you will likely want something for at least Windows 2000, because of the overhaul of the PnP system and more in Windows 2000.
OSR is also an excellent online resource, although I have to caution you: they are selling courses and those courses are excellent. Natrually they'll not provide every detail in the online available resources. I thought I knew something about driver programming, until I took two of their courses in 2005. They also host three mailing lists
Other than the difference between paged and nonpaged pool you will have to learn concepts such as IRQLs and what you can do at which IRQL. Also, most people think of drivers as "programs", which is another fallacy. One can more compare them with DLLs, even though this comparison also has its shortcomings. It is hard for drivers to maintain global state because many threads from various processes in UM and KM may be hammering it with requests. And all of this still has to be running at a reasonable speed. You may also want to learn tools such as WinDbg, even though with the new VS 11 WDK integration you may not need that anymore (VisualKD is an older option for the same problem).
If you think you can get away with Windows UM programming skills in KM, think again! The best scenario I can imagine is that your driver will be badly written and will work only because you used one of the more recent driver models from the WDF, which simplify many of the things that otherwise require in-depth knowledge. However, will it run reliably? You must consider that a crashing program just crashes the program, but your crashing driver will inevitably crash the OS, the repercussions of which may become clear only later. Especially when considering that PCs are also used in hospitals or nuclear power plants.
Also one last note: as I pointed out before you do not need Visual Studio at all. Be it the Express edition or another. The reason being that the WDK is reportedly a subset of the environment used to build the OS (i.e. Windows) itself. This means you can use Vim or whatever your favorite editor and still build your driver. After all, the build environment of the WDK is nmake-based, with an application named build on top and the sources file in your folder being the central file in your make process. Look at any one sample in the WDK, there are plenty. But most of all RTFM (read the friendly manual). The WDK documentation is excellent, especially if you have the comparison from Windows NT4, 2000 or even XP times.
I'm in an Assembly class focusing on the intel 8086 architecture (all compiling / linking / execution comes from running DOS on win7 via DOS-Box).
I've finished programming the latest assignment, but as I have yet to program any program successfully the first time through, I am now stuck trying to debug my code.
I have visual studio 2010 and was wondering if there was some built in feature that would help me debug my assembly code, specifically, I'm looking to track the value of a variable.
Failing that, instructions pointing to a DOS-Box debugger (and instructions!) would be much appreciated. (I think I've been able to run codeview debug, but I couldn't figure out how to do what I was looking for).
You are generating 16-bit code, you have to break into a museum to find better tooling. Try Borland's, maybe the debugger included with Turbo C.
Yes, indeed, you can use the debugger in VS to examine pretty much everything. Irvine's site has a section specifically on using the debugger here. You can examine registers, use the watch window, etc. He also has a guide for highlighting asm keywords if you need that.
Edit: as Hans pointed out, if you are using 16-bit instead of 32-bit protected, you'll need different tools. There are several choices, listed here.
Borland's tools for DOS were called tasm, tlink, and tdebug.
i, and a few thousand other people, are getting an error being thrown by the Microsoft Visual C++ Runtime:
Which for the benefit of search engines, says:
Microsoft Visual C++ Runtime Library
Buffer overrun detected!
Program: %s
A buffer overrun has been detected which has corrupted the program's
internal state. The program cannot safely continue execution and must
now be terminated.
Now i understand what a buffer overrun is, and why it is a bad thing. Given Microsoft's new emphasis on "it's just broken", the extra buffer checks in MSVCRT can be a nice thing.
On the other hand, i don't care. It's not that the program can't continue, it's that the program cannot safely continue. Well i'd rather be unsafe, because it's better than nothing. i enjoy living dangerously.
So can anyone suggest anything? i was thinking things like:
a registry key to prevent MSVCRT from halting execution
running the application in compability with a previous operating system (previous to Windows 7)
adding an assembly manifest to the executable folder so that it uses an older version of the MSVCRT, one which doesn't perform this overflow checking
a version number, or download location, of a copy of MSVCRT that doesn't have the overflow checking
i tried searching the support site of the company that wrote the Microsoft Visual C++ Runtime Library, but they have no mention of which functions could be overflowing, or how to disable overflow checking.
There is an option here. Set it to no.
Project Properties -> Configuration Properties -> C/C++ -> Code Generation -> Buffer Security Check.
This corresponds to the /GS (Buffer Security Check) compiler option:
Detects some buffer overruns that
overwrite the return address, a common
technique for exploiting code that
does not enforce buffer size
restrictions. This is achieved by
injecting security checks into the
compiled code.
Is this happening in you code or actually in the library? If it's in the library, I know you say you want to just ignore the error, but what you would you do if it was an access violation that crashed the process?
You should treat it the same way, because logically it's the same thing. It's just the CRT is crashing the process instead of the OS.
But, If you're using the debug build of the library you might get better (?) results using the release build (maybe it'll just crash without the dialog box notification).
If it's in your code you can disable the overflow check using the /GS- option. But you should really fix the bug.