CreateEx failes with EN_SYSTEM_CALL_FAILED

Dan203 · **Joined:** Thu Apr 27, 2006 12:32 am **Posts:** 99

OK I'm finally making some headway using this SDK, however now I'm getting errors when trying to search for devices. I'm using the code from the DeviceInfo sample which works fine. However in my code the CreateEx call is returning EN_SYSTEM_CALL_FAILED. Here is my code, can anyone tell me what's wrong?

Code:

LONG NumberOfDVDDevices = 0;
EXCEPTION_NUMBER ExceptionNumber = EN_SUCCESS;
ULONG SystemError = ERROR_SUCCESS;
ULONG Version = 0;
CHAR VersionText[1024];

ExceptionNumber = StarBurn_UpStartEx((PVOID)(&g__UCHAR__RegistrationKey ), sizeof(g__UCHAR__RegistrationKey));

if (ExceptionNumber == EN_SUCCESS)
{
   CHAR ExceptionText[ 1024 ];
   CDB_FAILURE_INFORMATION FailureInformation;
   ULONG ululSystemError = ERROR_SUCCESS;

   char Name[128] = "\0";

   int i = 0;
      
   //
   // Try to find all devices
   //
   for (i = 0; i < 20; i++)
   {
      PVOID pCdvdBurnerGrabber = NULL;

      EXCEPTION_NUMBER ExceptionNumber =
         StarBurn_CdvdBurnerGrabber_CreateEx(
            &pCdvdBurnerGrabber,
            (PCHAR) (&ExceptionText),
            sizeof(ExceptionText),
            &ululSystemError,
            &FailureInformation,
            (PCALLBACK) (FindCallback),
            NULL,
            Name,
            1
         );
      //
      // Check for success
      //
      if (ExceptionNumber == EN_SUCCESS)
      {
         if (pCdvdBurnerGrabber != NULL)
         {
            //
            // Free allocated memory
            //
            StarBurn_Destroy(&pCdvdBurnerGrabber);
            pCdvdBurnerGrabber = NULL;
         }   

         CString test;
         test.Format("%s", Name);
         AfxMessageBox(test);
      }
   }

   StarBurn_DownShut();
}

Here is what the ExceptionText variable reports

Quote:

ExceptionText 0x0012dbf0 "CStarBurn_ScsiTransportSPTI::CStarBurn_ScsiTransportSPTI(): CreateFile( '\\.\', 0xc0000000, 3, 0x00000000, 3, 0, 0x00000000 ) failed, status 123 ( 0x7b )" char [1024]

I've tried the code both statically and dynamically linked, and tried both a release and debug build. All of them fail in exactly the same way.

I also tried the ASPI version using just Create instead of CreateEx and that worked. However this app is targeted at XP, so I's like to use STPI if I can.

Thanks,
Dan

anton (staff) · **Posted:** Fri Mar 09, 2007 9:05 pm

Of course it would fail! You're passing void name to the function... Take a look at FindDeviceEx console sample and just cut-n-paste device enumeration loop to your app.

Dan203 · **Joined:** Thu Apr 27, 2006 12:32 am **Posts:** 99

OK well I couldn't copy it verbatim, but I was able to get it to work using that as a guide. Thanks, and sorry for my slightly hostile demeanor. I was just very frustrated that I couldn't get it to work.

Although I must still say the VC++ samples you've provided are very confusing and hard to work with. You should really consider redoing them as simple dialog based programs that people can easily dissect and use for building their own code. Or you could simply write an MFC wrapper class around the whole SDK that would make it easier for programmers to use.

Dan

anton (staff) · **Posted:** Mon Mar 12, 2007 11:17 pm

FindDeviceEx is 500 lines of code... With 3 lines of comments per every line of "C". I really cannot imagine anything simplier

Back to MFC samples - we're just done with re-doing it to MS-style wizards. In the way anybody could just cut-n-paste whole project into his app.

Keeping in mind 1) and 2) I don't think anybody is interested in having something in the middle (single form samples all other SDKs use - I personally hate this kind of stuff)

And yes, we're working on new ActiveX/OCX/.NET wrapper to make API isolated inside it. Current one is still to complex for the beginners.

Dan203 wrote:

OK well I couldn't copy it verbatim, but I was able to get it to work using that as a guide. Thanks, and sorry for my slightly hostile demeanor. I was just very frustrated that I couldn't get it to work.

Although I must still say the VC++ samples you've provided are very confusing and hard to work with. You should really consider redoing them as simple dialog based programs that people can easily dissect and use for building their own code. Or you could simply write an MFC wrapper class around the whole SDK that would make it easier for programmers to use.

Dan

Dan203 · **Joined:** Thu Apr 27, 2006 12:32 am **Posts:** 99

I know that the console apps are simple, but they're written in C and for people like me who learned to program strictly in VC++ they're a little confusing.

And the VC++ samples are pretty much worthless. Sure they work well when compiled but all the code is so spread out that it's darn near impossible to follow along and see exactly what it is doing.

As for people not wanting stuff in the middle... I'm not talking a complex abstraction layer here. I'm just taking about simple helper functions for some of the more common tasks. For example what would prevent you from providing a simple wrapper to Eject function that takes just a single argument (i.e. the drive letter) and ejects the disk if it can, then returns either true or false depending on whether the command was sucessfull or not? To do the same thing now I have to use Create or CreateEx to get a handle to the drive, test a couple of variable to make sure it didn't fail, then call Eject with a half dozen parameters then test those to make sure the eject command didn't fail. While I understand that all this added functionality makes the SDK more flexible, it also makes it a lot more complicated to work with. That's all I'm trying to say.

That being said your SDK works a lot better at it's core then the last one I was using, even if it is more complicated to program for, so I can't complain too much.

Dan

anton (staff) · **Posted:** Tue Mar 13, 2007 6:46 pm

It does not matter how difficult software is INSIDE it should be pretty easy to be used OUTSIDE. That's why you'll definitely love StarBurnX wrapper we'll release soon

Dan203 wrote:

I know that the console apps are simple, but they're written in C and for people like me who learned to program strictly in VC++ they're a little confusing.

And the VC++ samples are pretty much worthless. Sure they work well when compiled but all the code is so spread out that it's darn near impossible to follow along and see exactly what it is doing.

As for people not wanting stuff in the middle... I'm not talking a complex abstraction layer here. I'm just taking about simple helper functions for some of the more common tasks. For example what would prevent you from providing a simple wrapper to Eject function that takes just a single argument (i.e. the drive letter) and ejects the disk if it can, then returns either true or false depending on whether the command was sucessfull or not? To do the same thing now I have to use Create or CreateEx to get a handle to the drive, test a couple of variable to make sure it didn't fail, then call Eject with a half dozen parameters then test those to make sure the eject command didn't fail. While I understand that all this added functionality makes the SDK more flexible, it also makes it a lot more complicated to work with. That's all I'm trying to say.

That being said your SDK works a lot better at it's core then the last one I was using, even if it is more complicated to program for, so I can't complain too much.

Dan

#1 Burning Software

CreateEx failes with EN_SYSTEM_CALL_FAILED

Who is online