I'm using LibTiff v4.0.3.
I had it working perfectly in multibyte, but when i try to work with Unicode, I get a runtime exception.
I can render the problem down to a single line:
#include "tiffio.h"
int _tmain(int argc, _TCHAR* argv[])
{
TIFF* tif = TIFFOpenW(L"D:\\Myfile", "r");
}
And this will work perfectly: TIFF* tif = TIFFOpen("D:\\Myfile", "r");
I can't get the exact exception code, but the code stack looks like this:
msvcr110.dll!__crt_debugger_hook(int _Reserved) Line 60 C
msvcr110.dll!_call_reportfault(int nDbgHookCode, unsigned long dwExceptionCode, unsigned long dwExceptionFlags) Line 155 C++
msvcr110.dll!_invoke_watson(const wchar_t * pszExpression, const wchar_t * pszFunction, const wchar_t * pszFile, unsigned int nLine, unsigned __int64 pReserved) Line 139 C++
msvcr110.dll!_invalid_parameter(const wchar_t * pszExpression, const wchar_t * pszFunction, const wchar_t * pszFile, unsigned int nLine, unsigned __int64 pReserved) Line 85 C++
msvcr110.dll!_invalid_parameter_noinfo() Line 97 C++
msvcr110.dll!_read(int fh, void * buf, unsigned int cnt) Line 84 C
ConsoleApplication1.exe!TIFFFdOpen() C
ConsoleApplication1.exe!TIFFClientOpen() C
ConsoleApplication1.exe!TIFFFdOpen() C
ConsoleApplication1.exe!TIFFOpenW() C
ConsoleApplication1.exe!wmain(int argc, wchar_t * * argv) Line 21 C++
ConsoleApplication1.exe!__tmainCRTStartup() Line 533 C
ConsoleApplication1.exe!wmainCRTStartup() Line 377 C
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
I've tried using #err and #err,hr , but they show that there was no error.
How can I get the Unicode version to work ? Do I need to compile the library differently?
(I've checked and there's no check for the preprocessor variable UNICODE in libtiff....)
Turns out you need to compile the library a bit differently when linking to debug mode project in Unicode.
Go to your libtiff folder, and open nmake.opt for editing.
Change the compilation flags to use debug CRT dlls (/MDd):
OPTFLAGS = /Ox /MDd /EHsc /W3 /D_CRT_SECURE_NO_DEPRECATE
instead of just /MD
Now rebuild the library.
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\vcvars32.bat" x86
nmake /f makefile.vc [clean]
or for x64:
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\vcvars64.bat" amd64
nmake /f makefile.vc [clean]
Make sure your project links to that file when you're in the debug configuration
Related
I'm trying to write the character "Ā" (https://www.fileformat.info/info/unicode/char/0100/index.htm) into a C++11 UTF8 string (using u8 prefix).
const char *const utf8 = u8"Ā";
const char *const utf8_2 = u8"\u0100";
const char *const chars = "Ā";
const int utf8_len = strlen(utf8);
const int utf8_2_len = strlen(utf8_2);
const int chars_len = strlen(chars);
Running this under MSVC (16.2.4) results in:
utf8_len == 5
utf8_2_len = 2;
chars_len = 2;
Where:
utf8 == "Ä€"
utf8_2 == "Ä€"
chars == "Ä€"
The source file is set to UTF8 (without BOM).
Trying the same with Clang and GCC works as expected:
https://godbolt.org/z/PNZFCa
Does anyone know why this behaviour is occurring? Why is the u8 prefixed Unicode character being encoded as 5 bytes (when it should be 2)?
The Microsoft compiler assumes the local ANSI encoding for files without BOM, which is probably Windows-1252 in your case. If you run cl /? from the command line, you'll see the following command line switches:
...
/source-charset:<iana-name>|.nnnn set source character set
/execution-charset:<iana-name>|.nnnn set execution character set
/utf-8 set source and execution character set to UTF-8
...
Use /source-charset:UTF-8 or /utf-8 if you don't want to save with BOM.
Test code saved in UTF-8 without BOM:
#include <stdio.h>
#include <string.h>
int main()
{
const char *const utf8 = u8"Ā";
printf("%zu\n",strlen(utf8));
}
Output:
C:\>cl /nologo test.cpp
test.cpp
C:\>test
5
C:\>cl /nologo /utf-8 test.cpp
test.cpp
C:\>test
2
I'm on windows, qt 4.7. part of my code takes a FILE* from a file which is open for reading by another part of the system (legacy, C). I open a QTextStream as follows:
// file currently opened (readonly), and partially read
FILE *infile = function_to_get_file_pointer();
QTextStream is(infile, QIODevice::ReadOnly);
The second line crashes when built in release mode but is fine in debug. I can step through the debug version and see the QFile that is opened internally by QTextStream.
The most I've managed to get out of the windows call stack in release mode at the time of the crash is below:
ntdll.dll!77450226()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77450142()
msvcr80.dll!_lock_file(_iobuf * pf=0x71962148) Line 241 + 0xa bytes C
msvcr80.dll!_ftelli64(_iobuf * stream=0x71962148) Line 51 + 0x8 bytes C
QtCore4.dll!6708b87d()
QtCore4.dll!67099294()
QtCore4.dll!6713d491()
which could be a red herring but look like something's gone wrong trying to lock the file. Prior to this, I have enabled debug output for my code so I know that it is the QTextStream creation that is causing the problem.
I welcome any suggestions!
After some further digging, I have found that the file, although ASCII, is originally fopened with "rb" in order to stop the win32 CRT converting line endings from \r\n to \n.
I assumed this would be confusing Qt so modified the fopen to use "r" only. Then a comment below linked to here which shows that the FILE* should be opened in binary mode, e.g. "rb", so this is not a problem.
Trying tezrigs suggestion below, freopen on the FILE* gives the following:
msvcr100.dll!_crt_debugger_hook(int _Reserved=8633404) Line 65 C
msvcr100.dll!_call_reportfault(int nDbgHookCode=2, unsigned long dwExceptionCode=3221226519, unsigned long dwExceptionFlags=1) Line 167 + 0x6 bytes C++
msvcr100.dll!_invoke_watson(const wchar_t * pszExpression=0x00000000, const wchar_t * pszFunction=0x00000000, const wchar_t * pszFile=0x00000000, unsigned int nLine=0, unsigned int pReserved=8633376) Line 155 + 0xf bytes C++
msvcr100.dll!_invalid_parameter(const wchar_t * pszExpression=0x00000000, const wchar_t * pszFunction=0x00000000, const wchar_t * pszFile=0x00000000, unsigned int nLine=0, unsigned int pReserved=0) Line 110 + 0x14 bytes C++
msvcr100.dll!_invalid_parameter_noinfo() Line 121 + 0xc bytes C++
msvcr100.dll!_freopen_helper(_iobuf * * pfile=0x0083bc3c, const char * filename=0x00000000, const char * mode=0x013ee350, _iobuf * str=0x71962148, int shflag=64) Line 31 + 0x1f bytes C
msvcr100.dll!freopen(const char * filename=0x00000000, const char * mode=0x013ee350, _iobuf * str=0x71962148) Line 111 C
The exception code passed to _call_report_fault is 0x0000417 - Fatal Error: Unknown Software Exception, which isn't much help..
OK: more detail, and some self contained, replicable code (myfile.txt must be over 1000 chars long):
#include <QtCore/QCoreApplication>
#include "qtextstream.h"
#include <iostream>
int main(int argc, char *argv[])
{
// QCoreApplication a(argc, argv);
std::cin.get();
FILE *myfile = fopen("myfile.txt", "rb");
int c;
for(int i=0; i < 1000; i++)
c = getc(myfile);
fflush(myfile);
long pos = ftell(myfile);
QTextStream is(myfile, QIODevice::ReadOnly);
while(!is.atEnd())
{
QString in_line = is.readLine();
std::cout << in_line.toStdString();
}
fseek(myfile, pos, SEEK_SET);
fclose(myfile);
return 0;
}
All the following in release mode:
This lets me attach a debugger if I run outside visual studio. If I run in outside visual studio, it crashes.
If I attach to it once it has started from outside visual studio, it crashes on construction of QTextStream.
If I start it from inside visual studio with shift-F5 (i.e. running outside the debugger) it writes the contents of the file to the display.
likewise, when running under the debugger, it works as expected.
It is down to the dlls. I have a locally compiled set of dlls (created with MSVC2010) and using them to replace those in the main product solves the problem. Ditto with the test code. The release code was using Qt compiled with 2005, using msvcr80.
All credit to #KarstenKoop - feel free to post your answer here. The problem was due to Qt dlls that were using msvcr80.dll while the rest of the application was compiled using visual studio 2010 and thus using msvcr100.dll
This link explains the perils of mixing visual studio versions quite nicely
I'm working on a large C++ project under Visual Studio 2010 and think that there are some memory leaks inside. I tried the approach with including crtdbg.h but it does not help much as I don't see where the leaks occured. Defining new has 2 pitfalls: First it needs to be done in every cpp file which is not really an option, and 2nd it breaks with e.g. Boost. Using new(nothrow) or anything that uses boosts "has_new_operator.h" breaks this. [EDIT: It fails to compile as the redefined "new" has no overloads for something like "nothrow" or the "boost magic"] (Unless one defines "new" after all boost headers including headers referencing boost)
Last but not least: I have singletons. They are implemented using subclasses of the singleton template and a static function variable. One of them is a config container where one registers settings (pairs of strings and ints that are than stored in maps) Since the mem leak dump is called before deallocation of the singleton instance I get a massive amount of leaks for all those strings and the singleton itself.
Any way to have only the real leaks shown or make it dump after static object deallocation?
Which free tools can handle this case?
I have used the Visual Leak Detector with quite positive results. It is small and neat, and can be built into your project (assuming you have a running Debug configuration) in a matter of seconds:
https://vld.codeplex.com/
If set-up correctly (which can be done using the installer) then you only have to
#include <vld.h>
in one of your .cpp files for each module - that's it, the header will do the linking for you. You don't have to put it everywhere. Internally the tool uses the CrtDbg, so you have to have a debug build running in order for it to work.
It gives you debugger or text output after each run (if configured using a config file), even when not run through a debugger. It is not the most powerfull tool, but these usually cost some coin ;)
EDIT: There is a possibility to enable the VLD also in non-debug configurations by defining VLD_FORCE_ENABLE before including the header. But the results may be tempered with then.
EDIT: I have tried a fresh installation of VLD. Note that for VS2013 compilers the v2.4rc2 version must be used (or anything greater v2.3). Version v2.3 only works up until VS2010 compilers.
After installation I created a new project and set-up my include- and library-directories to include the respective VLD folders. After that I used the following code to test memleak reports of singletons (note that this code doesn't make sense, it just proves a point):
#include <iostream>
#include <string>
#include <sstream>
#include <map>
// Uncomment this, if you want VLD to work in non-debug configurations
//#define VLD_FORCE_ENABLE
#include <vld.h>
class FooSingleton {
private:
std::map<std::string, std::string*>
_map;
FooSingleton() {
}
public:
static FooSingleton* getInstance(void) {
/* THIS WOULD CAUSE LEAKS TO BE DETECTED
SINCE THE DESTRUCTOR WILL NEVER BE CALLEd
AND THE MAP IS NOT CLEARED.
*/
// FooSingleton* instance = new FooSingleton;
// return instance;
static FooSingleton instance;
return &instance;
}
void addString(const std::string& val) {
_map.insert(std::make_pair(val, new std::string(val)));
}
~FooSingleton(void) {
auto it = _map.begin();
auto ite = _map.end();
for(; it != ite; ++it) {
delete it->second;
}
}
};
int main(int argc, char** argv) {
FooSingleton* fs = FooSingleton::getInstance();
for(int i = 0; i < 100; ++i) {
std::stringstream ss;
ss << i << "nth string.";
fs->addString(ss.str());
}
return 0;
}
With this code, the VLD does not report any leaks because the static auto-variable in getInstance() will be destructed upon exit and the elements in the map will be deleted. This must be done nevertheless, even if it's a singleton, otherwise the leaks will be reported. But in this case:
Visual Leak Detector Version 2.3 installed.
Aggregating duplicate leaks.
Outputting the report to the debugger and to D:\dev\projects\tmp\memleak\memleak\memory_leak_report.txt
No memory leaks detected. Visual Leak Detector is now exiting.
If the code in the getInstance() is changed to the commented version, then the singleton is never cleared up and the following leaks (amongst others) is reported:
---------- Block 11 at 0x008E5928: 52 bytes ----------
Leak Hash: 0x973608A9 Count: 100
Call Stack:
c:\program files (x86)\microsoft visual studio 10.0\vc\include\xmemory (36): memleak.exe!std::_Allocate<std::_Tree_nod<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > *,std::less<std::basic_string<char,std::char_traits<char>,std::alloca + 0x15 bytes
c:\program files (x86)\microsoft visual studio 10.0\vc\include\xmemory (187): memleak.exe!std::allocator<std::_Tree_nod<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > *,std::less<std::basic_string<char,std::char_traits<char>,std::alloca + 0xB bytes
c:\program files (x86)\microsoft visual studio 10.0\vc\include\xtree (560): memleak.exe!std::_Tree_val<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > *,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,s + 0xD bytes
c:\program files (x86)\microsoft visual studio 10.0\vc\include\xtree (588): memleak.exe!std::_Tree_val<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > *,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,s + 0x8 bytes
c:\program files (x86)\microsoft visual studio 10.0\vc\include\xtree (756): memleak.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > *,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std:: + 0x17 bytes
d:\dev\projects\tmp\memleak\memleak\main.cpp (33): memleak.exe!FooSingleton::addString + 0xA9 bytes
d:\dev\projects\tmp\memleak\memleak\main.cpp (51): memleak.exe!main + 0x37 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (555): memleak.exe!__tmainCRTStartup + 0x19 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (371): memleak.exe!mainCRTStartup
0x76BF919F (File and line number not available): KERNEL32.DLL!BaseThreadInitThunk + 0xE bytes
0x7739A22B (File and line number not available): ntdll.dll!RtlInitializeExceptionChain + 0x84 bytes
0x7739A201 (File and line number not available): ntdll.dll!RtlInitializeExceptionChain + 0x5A bytes
Data:
C0 53 8E 00 30 67 8E 00 C0 53 8E 00 98 58 8E 00 .S..0g.. .S...X..
30 6E 74 68 20 73 74 72 69 6E 67 2E 00 CD CD CD 0nth.str ing.....
0C 00 00 00 0F 00 00 00 CD CD CD CD 48 56 8E 00 ........ ....HV..
01 00 CD CD
You can clearly see the Count: 100 for this block of code, which is correct.
I also edited my vld.ini file in the installation directory to have the following set to be enabled:
AggregateDuplicates = yes
ReportTo = both
These make sure that a) all duplicate leaks are squashed together to one report with a leak-count (as above, otherwise there would be 100 entries) and the other so that a report-file is dumped in the directory of the application.
So for singletons it works fine as long as you use the static auto-variable approach you are using and do your cleanup in the destructor.
EDIT: Also, the instrumentation can be disabled at specific code pieces. If the above code would be modified like this:
void addString(const std::string& val) {
VLDDisable();
_map.insert(std::make_pair(val, new std::string(val)));
VLDEnable();
}
The leaks will never be profiled and not tracked.
You can get memory leaks source from crtdebug. it won't help you with the boost allocations, unless you compile boost (or any library) in the same way, but for the rest, it will show you allocation file and line.
This is how you use properly the crtdebug.h:
in the top of your stdafx.h (or any PCH file) add the following lines:
#ifdef DEBUG
//must define both _CRTDBG_MAP_ALLOC and _CRTDBG_MAP_ALLOC_NEW
#define _CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC_NEW
#include <stdlib.h>
#include <crtdbg.h>
//if you won't use this macro you'll get all new as called from crtdbg.h
#define DEBUG_NEW new( _CLIENT_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif
Now in the beginning of your main or winmain or any entry point to your program add the following lines:
//register memory leak check at end of execution:
//(if you use this you won't need to use _CrtDumpMemoryLeaks at the end of your main)
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
//set report mode:
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );
Now here a small test I've made:
After a new console program from VS10 called "test":
My stdafx.h:
#pragma once
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC_NEW
#include <stdlib.h>
#include <crtdbg.h>
#define DEBUG_NEW new( _CLIENT_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif
#include "targetver.h"
#include <stdio.h>
#include <tchar.h>
and my test.cpp is:
#include "stdafx.h"
void CheckMemoryLeak()
{
char *ptr=new char[100];
int n=900;
sprintf(ptr,"%d",n);
}
int _tmain(int argc, _TCHAR* argv[])
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );
CheckMemoryLeak();
return 0;
}
Output is:
'tests.exe': Loaded 'C:\Users\shr\Documents\Visual Studio 2010\Projects\tests\Debug\tests.exe', Symbols loaded.
'tests.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'tests.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'tests.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'tests.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded.
Detected memory leaks!
Dumping objects ->
c:\users\shr\documents\visual studio 2010\projects\tests\tests\tests.cpp(9) : {97} client block at 0x01003288, subtype 0, 100 bytes long.
Data: <900 > 39 30 30 00 CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
The program '[1600] tests.exe: Native' has exited with code 0 (0x0).
The following code works as expected in VS2012, Debug build:
#include <SDKDDKVer.h>
#include <stdio.h>
#include <tchar.h>
#include <Windows.h>
#include <io.h>
#include <assert.h>
DWORD WINAPI childThread(LPVOID param) {
printf("I'm the child!\n"); fflush(stdout);
_isatty(-1);
//assert(1==0);
return 0;
}
void myInvalidParameterHandler(const wchar_t * expression, const wchar_t * function, const wchar_t * file, unsigned int line, uintptr_t pReserved) {
wprintf(L"%s:%i %s() - Invalid parameter [%s]", file, line, function, expression);
}
int _tmain(int argc, _TCHAR* argv[]) {
wprintf(L"Registering invalid parameter handler\n");
_invalid_parameter_handler newHandler = myInvalidParameterHandler;
_set_invalid_parameter_handler(newHandler);
printf("Testing.\n");
CreateThread(NULL, 0, childThread, NULL, 0, NULL);
// CreateThread(NULL, 0, childThread, NULL, 0, NULL);
printf("Thread(s) created, press Enter to exit.\n");
getchar();
return 0;
}
Parameter Validation will cause a "Abort/Retry/Ignore" popup from the childThread's _isatty(-1) and it stays around as long as necessary. If I hit "Ignore", then myInvalidParameterHandler is invoked, and the program runs until I hit Enter. All Good.
If the second CreateThread is uncommented so two Parameter Validation failures occur at once, then the program silently exits. Sometimes Abort/Retry/Ignore pops up, but it disappears within a second. The program never hangs around for main's getchar.
When run from within the debugger, it hits a breakpoint at:
msvcr110d.dll!_CrtDbgBreak() Line 87 C
msvcr110d.dll!_VCrtDbgReportW(int nRptType, void * returnAddress, const wchar_t * szFile, int nLine, const wchar_t * szModule, const wchar_t * szFormat, char * arglist) Line 506 C
msvcr110d.dll!_CrtDbgReportWV(int nRptType, void * returnAddress, const wchar_t * szFile, int nLine, const wchar_t * szModule, const wchar_t * szFormat, char * arglist) Line 262 C++
msvcr110d.dll!_CrtDbgReportW(int nRptType, const wchar_t * szFile, int nLine, const wchar_t * szModule, const wchar_t * szFormat, ...) Line 279 C++
msvcr110d.dll!_isatty(int fh) Line 41 C
assertTest.exe!childThread(void * param) Line 10 C++
This isn't a general problem of simultaneous assertions. If I swap commenting of _isatty(-1) and assert(1==0), then it does what I'd expect. We get two abort/retry/ignore popups, they hang around, and the main thread runs to completion.
Release builds don't have this problem, the invalid parameter handler is invoked for both threads and execution always continues.
For context, we had a long-running server process that was hitting _isatty(-1) in multiple threads and silently exiting. It's a problem that we've fixed, but this behavior made it very difficult to track down. I'm wondering if there's something that could be done to help.
I saw a question with similar behavior, but that was MinGW & was determined to be a compiler bug. I've verified that test works in VS2012.
Figured it out - somehow I'd gotten debugging disabled in my registry. They key Auto in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug was missing. Setting it to 1 caused the debugger named in the Debugger key, vsjitdebugger, to be invoked. Nothing disappears anymore!
Got the idea from http://support.microsoft.com/kb/188296 on disabling Watson.
I am calling a Fortran 77 Function from C++ that passes a file handle, a string, and the length. The files opens successfully and the Fortran subroutine exits. However, back in the C++ Code the string, which was passed to fortran, is corrupted. When the bottom of the function openFile is reached the program crashes.
The crash only appears in release but not in debug. Plotting the strings, I see that in release the variable fileNameToFortran is full of trash.
Thanks for your help
I use ifort with following compiler flags in release (windows 7 machine (32 bit)):
/names:lowercase /f77rtl /traceback /iface:cref /threads /recursive /LD
and in debug:
/names:lowercase /f77rtl /traceback /iface:cref /threads /recursive /LDd /Zi /debug:full /check:all /traceback
Here is the C-Code:
typedef void (FORTCALL *sn_openfile_func) (int *,
char[],
int *,
int);
void openFile(const int fileHandle, const std::string fileName)
{
int fileHandleToFortran = fileHandle;
char fileNameToFortran[20];
assert(fileName.size() < 20);
strcpy(fileNameToFortran, fileName.c_str());
int lstr = strlen(fileNameToFortran);
openfile_func_handle(&fileHandleToFortran, fileNameToFortran, &lstr, lstr);
}
Here is the Fortran Code:
SUBROUTINE SN_OPENFILE(FILENR,FILENAME,FSIZE)
!DEC$ ATTRIBUTES DLLEXPORT :: SN_OPENFILE
IMPLICIT NONE
INTEGER FILENR, FSIZE
CHARACTER FILENAME*FSIZE
OPEN (FILENR,FILE = FILENAME,
& ACCESS = 'SEQUENTIAL' , STATUS = 'REPLACE', ERR=222)
GOTO 333
222 WRITE(*,*) 'Error opening file'
333 END
OK, I found the answer myself.
The macro FORTCALL was defined as __STDCALL
Now, when using iface:cref it only crashes in release. That is strange, but after I have removed it, it works for release and debug.