Fatal error during graphic initialization

Hello all,

If you find errors below, give feedback, if it helps also.


It's true, there is about 7 subjects in this forum about this message :

[OS Context]
Platform : Win7 / 64bit
OCC6.5.1 Debug
target : win32

I've worked for more than ten years with OCC, I know this message quite well, usually it's easy to get rid of it, but recently I couldn't figure why I could not open 3dView anymore in my App (VS2008) ...
It didn't worked anymore even for OCC sample, even with batch files (*.bat) that does the work for env. var.

Usually the answer in this forum is Look at "CSF_GraphicShr" environment variable, it is not set properly.
A lot of people says in this forum it does not solve their problem, it's just because this simple assomption is not 100% true.
It's a starting point but not the solution.
Some beginners will go away probably just because of one line in OCC code.
You have to understand precisely what is happening. takes hours !

I personnaly don't use env. variables,, it's a unix approach, not always easy to check or not fast to configure.
You can use OSD_Environment
OSD_Environment anEnvironmentVariable(aKeyName);

I would prefer an xml SetOccConfiguration("occ_config.xml") but it's another discussion

[My end solution was :]

Change "d:\OpenCASCADE6.5.1\ros\src\OSD\OSD_SharedLibrary.cxx"

Standard_Boolean OSD_SharedLibrary :: DlOpen ( const OSD_LoadMode Mode ) {

// ( myHandle = ( HINSTANCE )LoadLibraryEx ( myName, NULL, LOAD_WITH_ALTERED_SEARCH_PATH) ) == NULL
// replaced by
( myHandle = ( HINSTANCE ) ::LoadLibrary (myName) ) == NULL

Recompile OCC entirely and it will probably work


[First Analysis :]
In fact CSF_GraphicShr is not really mandatory. You can delete it. It will take dllName="TKOpenGl.dll" by default
If you look code, OCC will try to Load Dll TKOpenGl.dll with this call ::LoadLibraryEx (dllName, NULL, LOAD_WITH_ALTERED_SEARCH_PATH);


*********************** **********************

void Graphic3d_WNTGraphicDevice::SetGraphicDriver ()
Standard_CString TheShr = getenv("CSF_GraphicShr");
if ( ! TheShr || ( strlen( TheShr ) == 0 ) )
TheShr = "TKOpenGl.dll";

MySharedLibrary.SetName ( TheShr );
Result = MySharedLibrary.DlOpen (OSD_RTLD_LAZY);

etc ...

Standard_Boolean OSD_SharedLibrary :: DlOpen ( const OSD_LoadMode Mode ) {
lastDLLError = GetLastError ();
} // end OSD_SharedLibrary :: DlOpen

*********************** CODE> **********************

*********************** CODE> **********************
void 3dViewerWnd::CreateIndependentViewer(V3d_TypeOfView aDefaultTypeOfView)
// if this not working dont go further
if (!ForceMyLoadTKOpenGL())

if (myGraphicDevice.IsNull())
myGraphicDevice = new Graphic3d_WNTGraphicDevice(); // call SetGraphicDriver

init 3dViewerWnd::ForceMyLoadTKOpenGL()
Standard_Address pHandle = NULL;
if ( ( pHandle ) == NULL &&
( pHandle = ( HINSTANCE ) ::LoadLibrary (MyT("TKOpenGl.dll")) ) == NULL
) {
// CString aString;
// MyTools::GetLastWin32Error(aString);
return 0;
return 1;

*********************** CODE> **********************

So you have to find why this dll Load fails.

Sources of problem can be
Mixing x64 with win32 compilation or
Release with Debug dll or
Multi-Threaded Dll with Single Threaded Dll or
Your Os can't find your Library.
Mixing OCC versions without knowing it (6.5.1 with 6.2.0)
You installed another software that use OCC and this software puts OCC dll in System32 (bad luck)
SetDllDirectory is called somewhere (your code or even not) and will redirect badly LoadLibraryEx call

Look all OCC Dll path in the Debug Window when they are being loaded by the sytem.
Search in your computer ALL "TKOpenGL.dll" and you could find some surprise.

Use Depends http://www.dependencywalker.com/ and Drag and Drop "TKernel.dll", "TKOpenGl.dll" then your exe inside it.

After, understand this notes :

[Windows documentation:]
Dynamic-Link Library Search Order
Note that the standard search strategy and the alternate search strategy specified by LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH differ in just one way:
The standard search begins in the calling application's directory, and the *** alternate search begins in the directory *** of the executable module that LoadLibraryEx is loading.
If a module changes the standard search order by calling the LoadLibraryEx function with LOAD_WITH_ALTERED_SEARCH_PATH, the system searches the directory the specified module was loaded from instead of the directory of the calling process. The system searches these locations in this order:

The package dependency graph of the process. This is specified in the section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.
The directory the specified module was loaded from.
The System directory (%SystemRoot%\system32).

If lpFileName specifies a relative path, the entire relative path is appended to every token in the DLL search path.
To load a module from a relative path without searching any other path, use GetFullPathName to get a nonrelative path and call LoadLibraryEx with the nonrelative path.
If the module is being loaded as a datafile and the relative path starts with .\ or ..\, the relative path is treated as an absolute path.
If lpFileName specifies an absolute path and dwFlags is set to LOAD_WITH_ALTERED_SEARCH_PATH, LoadLibraryEx uses the altered search path. *** LOAD_WITH_ALTERED_SEARCH_PATH does not work with relative paths. ***
Alternate Search Order for Desktop Applications

The standard search order used by the system can be changed by calling the LoadLibraryEx function with LOAD_WITH_ALTERED_SEARCH_PATH. The standard search order can also be changed by calling the SetDllDirectory function.

So what you can try first :
::LoadLibrary ("TKernel.dll") Doest it work ?
yes : continue, no : check your "Path" env Variable and get error code and message associate with it

::LoadLibrary ("TKOpenGl.dll") Doest it work ?
yes : your CSF_GraphicShr is not set properly or check there is no OCC dll in your App Directory. No : continue or call this before new Graphic3d_WNTGraphicDevice();

::LoadLibrary ("D:\\OpenCASCADE6.5.1\\ros\\win32\\vc9\\bind\\TKOpenGl.dll") Doest it work with your full path ?
yes : check your "Path" env Variable and check there is no OCC dll in your App Directory. You could think one Dll is used and in fact it's another one
no : check the full path between "", then clean and recompile OCC Project entirely and check before the platform, the lib and include path, "VCVER" env Var, "OS_TYPE" env var. (vc9, win32 for ex)

If like me it does not work after all that awful work :
1°) workaround is call ::LoadLibrary("TKOpenGl.dll") before OCC call to "new Graphic3d_WNTGraphicDevice(); "
2°) change OCC code in OSD_SharedLibrary :: DlOpen () then recompile OCC

Hope this approach will helps.
If I find the solution without changing OCC code, I will post it.


Heinz R.'s picture

Hi Philippe,

working with OpenCascade for beginners is hard going. I'm working some years with OCC under Windows XP SP3 and with MS Visual Studio 2008 SP1.

I agree with your observation that the answers in the forum on the failure with graphic initialization are always the same: enviroment settings are wrong
and it helps not.

I have now a curious occurrence:

My application is starting in debug-Modus with OCC 6.5.0 (compiled with VS 2008) as well under Win XP as Windows 7 64 bit prof. Both OS on different hardware. No problem.

If I try to start my application with OCC 6.5.1 (also compiled with VS 2008) under Win XP it works well, with Windows 7 64 bit the application start crashed with the wellknown failure :

On the same hardware with the same OS (Win 7 64 bit) and the same enviroment settings OCC 6.5.0 and OCC 6.5.1 has a different behaviour ? A beginner has to be frustated if he failed at these things.
Does this makes any sense ?

I think the whole installation routine of OCC has to be overhauled. The procedures are to difficult for beginners.

Forum supervisor's picture

Dear hinzman,
I have checked the OCC6.5.1 in the specified environment: VS2008, Windows 7 X64 bit prof. The problem is not reproduced. Probably you didn't follow the published instructions for OCCT rebuilding or did it in a customized way.

The OCCT rebuilding instructions are very simple.
1)First you need to rebuild third parties libs to be used with OCCT.
Html documentation delivered with the release gives good road-map for this.
See chapter "Welcome to Open CASCADE Technology/Compilation of third-party products used for OCCT/Recommendations for compilation".
As result you should get in '3rdparty' directory the next structure of the rebuilt third parties:


Projects' options are well defined in the specified chapter too.

2) Second step is rebuilding of OCCT itself.
It's also well defined in the chapter "Welcome to Open CASCADE Technology/Building Modules/Building Modules".
It is in fact the easiest step. Pay you attention to the last note:
" ...
Use script msvc.bat located in the ros sub-folder of OCCT installation directory for launching MS Visual Studio in the environment configured for building OCCT libraries. The script accepts optional arguments: the version of Visual Studio to launch (vc8, vc9, or vc10), the architecture (win32 or win64), the mode of libraries to use for execution (Debug or Release), and the path to the solution file."

For you case it may be like the next
msvc.bat vc9 win64 Release
After that you should just rebuild the solution.

3) Check step (using Draw application).
Use script draw.bat located in the ros sub-folder of OCCT installation directory to run Draw:
draw.bat vc9 win64 Release

> pload ALL
> box b 100 100 100
> vinit
> vdisplay b
> vfit
> vsetdispmode 1

After that you will see in 'Test3d' window the just built box 'b' in shading mode.
The displayed box proves that there is no problem with Viewer3d services.

Heinz R.'s picture

Thank you very much for your help.

but I compiled the third-party libs on my 64-bit machine Windows 7 64 bit VS 2008 SP1 in accordance to the documentation as 32 bit versions without any problems.
I rebuilded OCCT 6.5.0 and 6.5.1 as 32 bit version too in debug and release modus without any failure.
My application project compiled and linked against OCC 6.5.0 starts in 32 bit debug modus, with OCC 6.5.1 crashes with above mentioned failure while starting. That is what I do not understand.
Maybe it is my specific problem, so I will work further with OCC 6.5.0.

After finishing my works I will follow your instructions to compile and rebuild everything in 64 bit with OCC 6.5.1.
I will report.

Jerome Monaco's picture

Hi, I do not know if it can help but when TKOpenGL.dll is loaded windows try also to load dependent libraries like ftgl_dynamic_MTD.dll.
Just try to copy all dependents dll in the same folder as TKOpenGL.
Hope this help
Best regards

hero's picture

Dear Philippe

so do you mean that the final solution for the problem is to do "THIS ONLY"

Change "d:\OpenCASCADE6.5.1\ros\src\OSD\OSD_SharedLibrary.cxx"

Standard_Boolean OSD_SharedLibrary :: DlOpen ( const OSD_LoadMode Mode ) {

// ( myHandle = ( HINSTANCE )LoadLibraryEx ( myName, NULL, LOAD_WITH_ALTERED_SEARCH_PATH) ) == NULL
// replaced by
( myHandle = ( HINSTANCE ) ::LoadLibrary (myName) ) == NULL

Recompile OCC entirely and it will probably work

because I did set "CSF_GraphicShr" environment variable properly but I still have the problem

waiting for help


shmsh's picture

Dear Philippe Carret ......

I had the same problem of Graphic initialization ....
I did set "CSF_GraphicShr" environment variable
and I replaced :
myHandle = ( HINSTANCE )LoadLibraryEx ( myName, NULL, LOAD_WITH_ALTERED_SEARCH_PATH) ) == NULL
myHandle = ( HINSTANCE ) ::LoadLibrary (myName) ) == NULL

and then I recompiled OCC but then I had the same problem so what is wrong then ??????

Thanks in advance


Arivazhagan's picture

Hi supervisor,
Iam new to opencascade and using version 6.5.5
My os is win 7 64 bit and using VS 2008 sp1
When i tried to compile the samples (after changing the directory to OCC 6.5.5 directory for lib, include and exec files) I get the following error.

Geometry.exe- system error

The program can't start because TKBRep.dll is missing from your computer. Try reinstalling the program to fix the problem.

Can you help me in this ?

Should I need to reinstall OCC 6.5.5.?

Forum supervisor's picture

Dear Arivazhagan,
OCCT6.5.5 built with another settings (vc9, win32, release mode) than you specified.
I do hope you read this thread carefully and now have general understanding
of the OCCT rebuilding process.
So, before trying to compile samples rebuild first all prerequisites necessary for samples (follow the instruction of this thread).
Best regards

Arivazhagan's picture


Thank you for the reply.
I will go through the forum.

Also would like to know that whether you are mentioning that occ6.5.5 will not run in 64 bit versions? or is there i need to do lots of changes i need to do in occ6.5.5 settings ?
your answer is not so clear - request you for a clarification as iam new to occ6.5.5

Also TKBrep.dll is available in the system but as said it is giving the error. Then how come i can atleast test the occ6.5.5 is installed properly.

I have spent more days on this issue.

Please correct me if Iam somewhere wrong here

Thank you in advance,

Forum supervisor's picture

Dear Arivazhagan,
I suggest you to read first Release Notes of OCCT more carefuly (see chapter
"Supported Platforms and Pre-requisites").
==> The official release of OCCT for Windows contains libraries built with VC++ 2008 in 32 bit mode.
For all other settings you should rebuild it by your own.
Best regards

Arivazhagan's picture

Dear Supervisor,

Thank you for the reply and suggestion.
I have successfully compiled the program....samples.....even my own code.

I strongly suggest who ever read this forum topic please also take a look at the following links.

It is easier for a beginner to implement OCC.



Iam sure you will be implementing OCC successfully.