Toolkit Scripts Receiving failed to start error.

[MH_10366957]

Creo Toolkit registry file xxx/creotk.dat : application 'xxx' failed to start; see trailfile for details.

I am receiving this error when I am trying to launch some OTK dll script in Creo 9.

I am using Object Toolkit C++ on Creo 9.0.1.0. I am updating OTK scripts that all worked successfully on Creo 5. However, now, after updating everything, I can get the DLL's to all compile successfully, but after unlocking the scripts and registering them in the Registry file, only some work while the others receive the above error. Is there another location where the error details appear so I can do some more trouble shooting?

Any and all help would be greatly appreciated.

Thanks,

Mark Hardebeck

[MartinHanak]

Hi,

I suggest you to contact PTC Support.

[YaroslavSin]

Do you have this files?

'Legacy toolkit Application Runtime' option is checked within the Creo installation.
-> The following files exist in the Creo xxxx/Common Files/x86e_win64/lib folder of the
installation:
• udata46.dll
• udata64.dll
• ucore46.dll
• ucore64.dll

[MH_10366957]

Yes, those files are there.

[FV]

There could be a number of reasons.

• Creo 9 had 'obsoleted' quite a number of old functions, but 'obsoleted' functions do not fail compilation...
• could be as simple as the app cannot access its message file...
• could be a config.pro setting and/or installation option related to 'legacy toolkit' application...

you could start a debugger session, connect to xtop.exe process (with no apps running yet), set breakpoints in the user_initialize function, start the app via UI command, step through debugger.  At least it will tell you where your app is failing.

HIH.

[MH_10366957]

I'll try that out, thanks for the help

[MH_10366957]

The error is coming from any functions that I have defined in another lib that I am importing and calling in the main dll. That lib compiles fine, and importing it into my dll that I am using for the toolkit script also compiles with no errors. Do you know what I should do about this?

MH

[YaroslavSin · Accepted solution]

The lib is a dll file? Try to add full path to dll folder into environment variable PATH.

[MartinHanak]

Hi,

do not forget that PATH variable can be modified in parametric.psf file.

[MH_10366957]

Sorry if my wording was unclear, the lib is a lib file, but should I still add it to the environment variable PATH?

[FV]

if you are using a statically linked libraries - 'PATH' environment variable will have no bearing on the link process. The locations of static libraries are controlled by switches to link.exe ( or by visual studio project settings which eventually would end up as switches).

even if your external library compiles with no errors it just means that a compiler (cl.exe) was able to make object files out of your source code files.

Make another visual studio project as 'simple asynchronous', Statically link with your library, In the main(...) call a couple functions from your library, Trace calls in debugger. When you are building this project - make sure that VS configurations are the same between libraries, all are using the same C++ standard, all are using the same SDK versions and platform toolsets, character sets ( multi-byte), run-time library (MT). Try to set compiler to treat warnings as errors in that project.

[MH_10366957]

After debugging and trying to figure out what is causing the library linking bug, I also discovered that when I start my toolkit, it disappears from the auxiliary apps list. I tried looking on the trail file to see if there was an error I missed, but the trail file just said that the toolkit started successfully.

[MH_10366957]

Sorry, for clarity, I commented out nearly all functionality from my script and kept only user_initialize, user_terminate, and a cpp file that prevents a linker error. After compiling with only those barebones remaining, my toolkit would disappear from the auxiliary apps list after it successfully started.

[FV]

this would happen if 'allow_stop' setting in protk.dat was not set or was set to 'FALSE' 

[MH_10366957]

That worked, thanks

[MH_10366957]

I have been able to determine that the errors I am receiving are being caused by me declaring a function like this 

#define DllExport __declspec( dllexport )
DllExport void Foo(void *i);

Or if I have the function being exported in a definition file.

?Foo@@YAXPEAX@Z @1

Am I missing a setting or something to get these to work in creo?

[FV]

for non-mangled static libraries, the common approach is to wrap function declarations with 'extern "C" ' in header files

#ifdef __cplusplus
extern "C" {
#endif

// declarations here

#ifdef __cplusplus
}
#endif

[MH_10366957]

Mine are set up like extern void Foo(void *dataPtr); in the header files.

I was incorrect in stating that I am importing these functions from static libraries. I am pulling my external functions from a DLL. I tried declaring the full path of the DLL to my PATH environment variable as well as I placed the full path in the psf file, to no avail. In the psf I have it defined as ENV = C:\Users\xxx\xxx\x64\release 

[FV]

try using run-time linking instead of load-time liking.

run-time would allow to see dll load problem while debugging.

or use ProToolkitTaskExecute(...) .