Skip navigation
Currently Being Moderated

Null pointer exception in cs3&4 but not in cs5 / Get Plugin folder/path

Jun 26, 2010 6:46 AM


PMString appfold;


string fname = appfold.GetPlatformString();

fname.append("/Plug-ins/myPlugin.pln"); //<----- c0000005 exception in cs3&4 but not in cs5


This code works fine with CS5.

It compiles with CS3 and 4 SDK, but gives Exeption c0000005 (AccessViolation because of writing to a Null Pointer). This happens on a windows 7 machine (i did not test other operating systems).


I tried many other way to receive the indesign folder and append the plugin subpath and filename to it. I either receive the c0000005 exception when trying to modify the std::string received from GetPlatformString() or directly after the functions return. The code of the hole function is the same for cs3,4 and 5.


There is another (new) post about a c0000005 exception that occurs on windows 7 but doesn't on windows xp:


If anybody has a solution, either by solving this normally very trivial pointer problem or by posting another way to get a plugins path please help.


  • Currently Being Moderated
    Jun 27, 2010 4:50 PM   in reply to nope0000

    First off, a dumb question: are you using this code in a thread?

    CS5 is very picky about not liking InDesign framework calls in a thread.

    You could try a Win native code for creating this path and see if that crashes.




    Alternatively we could approach the code completely differently.

    You said you tried a few ways, but how about something like:


    IDFile aFile;


    FileUtils::AppendPath(&aFile, "Plug-ins");

    FileUtils::AppendPath(&aFile, "myPlugin.pln");

    PMString thePath = aFile.GetString();



    Mark as:
  • Currently Being Moderated
    Jun 27, 2010 10:51 PM   in reply to nope0000

    This does not address the reason why things crash, but it does address your main goal: getting the path of your plug-in.


    AFAIK, you'd be better to consult IID_IPLUGINLIST on the session boss. That gives you access to the path to your plug-in.


    In the incomplete, untested sample below, kMyPluginID stands for your plugin's ID (see your ...ID.h file).


    do {


            ISession* session = GetExecutionContextSession();

            InterfacePtr<IPlugInList> pluginList(session, IID_IPLUGINLIST);

            if (pluginList == NULL)

                break ;


            IDFile path;

            if (! pluginList->GetPathName(kMyPluginID, &path))


    while (false);
    Something like that (waves hands)...

    Mark as:
  • Currently Being Moderated
    Jun 28, 2010 1:31 PM   in reply to nope0000

    I suspect the crash is a symptom of something deeper and/or earlier - some interface pointer that got released prematurely/too often, some memory that got overwritten. Those kinds of things tend to result in 'delayed crashes' in seemingly unrelated areas of the code - it all depends what got overwritten or what area got affected by the extra Release() call.


    Make sure you're using the debug version.


    Double-check your InterfacePtr<...> management (do a global source-code search for creations of them throughout your code and visually verify ALL of them. GREP is your friend) and make sure they're all the correct type (1-param vs. 2- or 3-param version: rule of thumb: the former needs to be used with Query... or Create... calls, the latter with Get... calls).


    Double-check your memory allocations; look for signs of overrun.


    Study the crash closer (look at the stack crawl).


    Switch platforms (Mac to Win or vice versa).







    Mark as:
  • Currently Being Moderated
    Jun 29, 2010 10:01 AM   in reply to nope0000

    I would suggest you to use


    PluginID plugInID=GetPlugIn()->GetPluginID();


    to get your PlugIN ID




    if (listOfPlugin==nil) {




    bool16 pOK=listOfPlugin->GetPathName(plugInID,&idFileName);

    if (pOK==kFalse) {







    then try the same code. I use similar method in CS5, CS4, it never failed.

    Mark as:
  • Currently Being Moderated
    Jul 8, 2010 4:55 AM   in reply to nope0000

    The reference returned by GetPlatformString will still reference the same memory as the PMString, and when the PMString goes out of scope you will get this error if you try to use the string. You need to use GetPlatformString().c_str() and the problem should fix itself.


    And as other people have mentioned it's better to stick to IDFile for as long as possible when handling paths to make InDesign handle platform specifics.

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points