Random crashes? huh?

**cpjust** · 07-08-2008

I think I found the cause of the LoadLibrary() problems. If I comment out this line in DllMain(), it never fails to load:

Code:

BOOL APIENTRY
DllMain( HANDLE /*hModule*/,
		 DWORD  ul_reason_for_call,
		 LPVOID /*lpReserved*/
		)
{
	TRACE( "*** DllMain() ***" );

    switch (ul_reason_for_call)
	{
		case DLL_PROCESS_ATTACH:
			TRACE( "DLL_PROCESS_ATTACH" );
//			CUExit::ReadCfgFile();
			break;
		case DLL_THREAD_ATTACH:
			TRACE( "DLL_THREAD_ATTACH" );
			break;
		case DLL_THREAD_DETACH:
			TRACE( "DLL_THREAD_DETACH" );
			break;
		case DLL_PROCESS_DETACH:
			TRACE( "DLL_PROCESS_DETACH" );
			break;
    }

	return TRUE;
}

bool
CUExit::ReadCfgFile()
{
	TRACE( "*** CUExit::ReadCfgFile() ***" );
	Tifstream fin( "UExit.cfg" );

	if ( !fin )
	{
		TRACE( "readCfgFile():  Failed to open file UExit.cfg!" );
		return false;
	}

	if ( !std::getline( fin, m_ScriptToCall ) )
	{
		TRACE( "readCfgFile():  getline() failed!" );
		return false;
	}

	TRACE( _T("readCfgFile():  m_ScriptToCall = '") + m_ScriptToCall + _T("'") );
	return true;
}

EDIT: Oh crap, I spoke too soon...

**MacGyver** · 07-08-2008

Are you allowed to do that kind of work in DLLMain()? I would expect so, but from this article I think you should just do the most basic initialization of variables:

http://msdn.microsoft.akadns.net/en-.../ms682583.aspx

Perhaps you should call that function in your DLL from your EXE.

**CornedBee** · 07-08-2008

You shouldn't take any locks in DllMain, and the streams often do internal locking, so it's risky.

**cpjust** · 07-08-2008

Originally Posted by CornedBee

You shouldn't take any locks in DllMain, and the streams often do internal locking, so it's risky.

OK, I moved it into a different place. Now DllMain() does nothing but return TRUE, but when I loop through several dozen LoadLibrary/FreeLibrary calls I get eventually get "Not enough storage is available to process this command." I put a 50ms sleep between LoadLibrary/FreeLibrary calls in case it was a timing issue, but that didn't help.

I also tried building new projects in VC++ 6.0 (using the same source files) and it's giving the same results.

**MacGyver** · 07-08-2008

Do you have any global or static objects in the DLL?

**cpjust** · 07-08-2008

Originally Posted by MacGyver

Do you have any global or static objects in the DLL?

Not anymore.
Although I'm still getting bad_alloc's and the "Not enough storage is available to process this command." LoadLibrary() errors after loading/unloading the DLL about 20-30 times.

These are the header files included in the DllMain file; I don't know if they have any objects in them that would cause any problems?

Code:

#include <windows.h>
#include <tchar.h>
#include <conio.h>	// DEBUG ONLY
#include <fstream>
#include <sstream>
#include <cstdio>		// For _spawnv() & _wspawnv().
#include <process.h>	// For _P_NOWAIT.

**cpjust** · 07-09-2008

OK, I've stripped this down to the bare bones and LoadLibrary() still fails after 20-30 calls:

stdafx.h:

Code:

#if !defined(AFX_STDAFX_H__7B54890C_3655_4A2C_BA76_444CC4D20F7E__INCLUDED_)
#define AFX_STDAFX_H__7B54890C_3655_4A2C_BA76_444CC4D20F7E__INCLUDED_

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000

// Insert your headers here
#define WIN32_LEAN_AND_MEAN	// Exclude rarely-used stuff from Windows headers

#include <windows.h>
#include <tchar.h>

#endif // !defined(AFX_STDAFX_H__7B54890C_3655_4A2C_BA76_444CC4D20F7E__INCLUDED_)

UExit.h:

Code:

#ifndef UEXIT_H_INCLUDED_JULY_2_2008
#define UEXIT_H_INCLUDED_JULY_2_2008

#ifdef _XDLL
#  define UEXIT_API __declspec(dllexport)
#else
#  define UEXIT_API __declspec(dllimport)
#endif

#endif	// UEXIT_H_INCLUDED_JULY_2_2008

UExit.cpp:

Code:

#include "stdafx.h"
#include "UExit.h"

BOOL APIENTRY
DllMain( HANDLE /*hModule*/,
	 DWORD  ul_reason_for_call,
	 LPVOID /*lpReserved*/
	)
{
	switch (ul_reason_for_call)
	{
		case DLL_PROCESS_ATTACH:
			break;
		case DLL_THREAD_ATTACH:
			break;
		case DLL_THREAD_DETACH:
			break;
		case DLL_PROCESS_DETACH:
			break;
	}

	return TRUE;
}

TestHarness.cpp:

Code:

#include "stdafx.h"
#include <iostream>
#include <cstdlib>

using namespace std;


HMODULE
LoadDLL()
{
	HMODULE hDLL = LoadLibrary( _T("UExit.dll") );

	if ( hDLL == NULL )
	{
		cout << "Error loading DLL!" << endl;
		exit( 1 );
	}
	else
	{
		cout << "DLL Loaded successfully." << endl;
	}

	return hDLL;
}

void
UnloadDLL( HMODULE&  hDLL )
{
	if ( hDLL == NULL )
	{
		cout << "The DLL isn't loaded!" << endl;
	}
	else
	{
		if ( FreeLibrary( hDLL ) == FALSE )
		{
			cout << "Error unloading DLL!" << endl;
		}
		else
		{
			cout << "DLL unloaded successfully." << endl;
			hDLL = NULL;
		}
	}
}

int main()
{
	HMODULE hDLL = NULL;

	for ( int i = 0; i < 1000; ++i )
	{
		cout << "*** " << i << endl;
		Sleep( 50 );
		hDLL = LoadDLL();
		Sleep( 50 );
		UnloadDLL( hDLL );
	}

	return 0;
}

How can THIS possibly be failing???

**CornedBee** · 07-09-2008

Windows is broken? Have you googled for similar things?

**medievalelks** · 07-09-2008

Moral of the story: prefer static linking.

**CornedBee** · 07-09-2008

Minimal example (sans the no-op switch in DllMain) runs fine on my computer - currently at 400.

**cpjust** · 07-09-2008

Originally Posted by CornedBee

Minimal example (sans the no-op switch in DllMain) runs fine on my computer - currently at 400.

Which compiler?
Can you post the Compile & Link options? Maybe I've got something messed up there?
Here are my settings for the UExit.dll:

Code:

/O2 /GL /I "..\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "UNICODE" /D "_UNICODE" /D "_XDLL" /D "_WINDLL"
/FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W4 /WX /nologo /c /Zi /TP /errorReport:prompt


/OUT:"D:\Programming\C++\UExit\x86-vc8\Release\UExit.dll" /INCREMENTAL:NO /NOLOGO /DLL /MANIFEST /MANIFESTFILE:"Release\UExit.dll.intermediate.manifest"
/DEBUG /PDB:"d:\Programming\C++\UExit\x86-vc8\Release\UExit.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

and the Test Harness:

Code:

/O2 /GL /I "..\include" /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "UNICODE" /D "_UNICODE" /D "_CRT_SECURE_NO_WARNINGS"
/FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W4 /WX /nologo /c /Zi /TP /errorReport:prompt


/OUT:"D:\Programming\C++\UExit\x86-vc8\Release\TestHarness.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Release\TestHarness.exe.intermediate.manifest"
/DEBUG /PDB:"d:\Programming\C++\UExit\x86-vc8\Release\TestHarness.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

**dwks** · 07-09-2008

Sounds a bit like this: http://forums.msdn.microsoft.com/en/...-1398db52a6ba/

This thread's even better: http://www.gamedev.net/community/for...opic_id=440135

But I don't know if that answers your question or not . . . .

**CornedBee** · 07-09-2008

VC++.Net 2003, default empty Win32 DLL & Console app, debug build.

**cpjust** · 07-09-2008

Originally Posted by CornedBee

VC++.Net 2003, default empty Win32 DLL & Console app, debug build.

Sonofa..........! I just created a brand new DLL and Console project in VC++ 2008 express and compiled those files, and it ran with no problems whatsoever (although I used a newer compiler than at work and I'm running Vista instead of XP).

The only differences in compiler options are the addition of these switches: /Oi /Gy
and these Linker options: /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DYNAMICBASE /NXCOMPAT

EDIT: and then I removed those differences too and it still worked. I think this might be a good excuse for me to work at home from now on.

Thread: Random crashes? huh?

Thread Tools

Search Thread

Display

Similar Threads

random to int?

Lesson #3 - Math

Another brain block... Random Numbers

How do I restart a random number sequence.

Best way to generate a random double?