I'm running into a an issue with SDK Version 1.06 and Nero 7 and am wondering if anyone else has seen the issue and if any one has any ideas. Let me layout the issue. The following is a the minimum set of code that is required to see the issue:

NERO_SETTINGS neroSettings;
CString langString("nero.txt");
CString vendString("ahead");
CString softString("Nero - Burning Rom");
CString filesPath("NeroFiles");

neroSettings.nstLanguageFile = langString;
neroSettings.nstNeroFilesPath = filesPath;
neroSettings.nstVendor = vendString;
neroSettings.nstSoftware = softString;

if (NeroAPIGlueConnect(NULL))
{
NEROAPI_INIT_ERROR initErr = NeroInit(&neroSettings,NULL);

if (initErr == NEROAPI_INIT_OK)
{
NERO_SCSI_DEVICE_INFOS *infos = NeroGetAvailableDrivesEx(MEDIA_NONE,NULL);
NeroFreeMem(infos);

NeroClearErrors();
NeroDone();
NeroAPIGlueDone();
}
}

The issue I'm seeing is that on occasion I'll receive an access violation when I'm closing down Nero (NeroAPIGlueDone). After tracing and debugging for a long time I noticed the following:

When NeroGetAvailableDrivesEx is called it creates two threads that have a starting address that points to code inside the NeroErr.dll at location base_module_address + 7ED3. The call succeeds as does the call to NeroFreeMem. When calling NeroDone one of the threads will exit, but on occasion the other one does not, but the call to NeroDone reports everything is cool. We then proceed to call NeroAPIGlueDone which unloads the NeroErr.dll from memory. At some point after this the Access Violation occurs and it's coming from the thread that did not exit during the call to NeroDone. The AV from that thread occurs in the address space where NeroErr.dll was loaded at base_module_address + 7E6B. The AV of course makes sense because the NeroErr.dll was unloaded by NeroAPIGlueDone. The real issue however is the fact that one of those two threads did not exit during the call to NeroDone. As stated earlier this does not happen all the time so executing the above code once might not yield the error; however, wrapping the above code in a while(true) loop always produces the error. Has anyone else seen this issue? Is there a step in tearing down nero that I'm missing? Does anyone know if we can get the Debug symbols for Nero so I can dig deeper into the issue? BTW, I'm running Windows XP SP2 and am using Visual Studio 2005 to develop a native exe. Any help or ideas would be greatly appreciated.

I have a similar behaviour. NeroGetAvailableDrivesEx creates additional threads. Using VS2003, Nero 5 and API Version 5582 those threads remained until the host application terminated.

With VS2005, Nero 7 and the same API-Version these threads terminate at some point after calling NeroAPIGlueDone and crash. I exchanged the API Version and I stepped back to VS2003. The problem remained. So it seems to be an issue of Nero 7. Debugging the program step by step reduces the frequence of occurence, wait loops won't help.

The only workaround that I can currently think of would be to initialize the API once in the program instead of initializing it multiple times whenever it's needed.