locked
App certification problem

    Question

  • Hi,

    I've written a small WinRT component that provides some DirectX drawing functionality to a Metro app. The app isn't a game, DirectX is used to render to an image.

    To keep things portable, most of the classes in the component are standard C++ classes, as opposed to ref classes. However, I'm having a problem with a particular piece of functionality which runs ok but fails the app certification test.

    The Visual Studio template-generated DirectX app has a function called CubeRenderer::CreateDeviceResources() which reads in shader files and creates the shader (using tasks), and I've placed essentially the same (private) member function on one of my internal classes. It runs OK, but I'm finding that I need to make the class a ref class otherwise the app certification fails with errors like:

    • File C:\Projects2012\App1\Debug\App1\AppX\App1.exe has failed the WXCheck check.
    • File C:\Projects2012\App1\Debug\App1\AppX\App1.exe has failed the SafeSEHCheck check.

    and

    • API GetModuleFileNameW in kernel32.dll is not supported for this application type. App1.exe calls this API.
    • API GetModuleHandleW in kernel32.dll is not supported for this application type. App1.exe calls this API.
    • API LoadLibraryExW in kernel32.dll is not supported for this application type. App1.exe calls this API.
    • API LoadLibraryW in kernel32.dll is not supported for this application type. App1.exe calls this API.
    • API lstrlenA in kernel32.dll is not supported for this application type. App1.exe calls this API.

    Can anyone give me any insight into what might be happening?

    Robert

    Saturday, July 07, 2012 3:10 PM

Answers

  • Jeff,

    I don't think so. I've resolved this now, but I did quite a bit of code reorganization, so I'm not sure exactly what fixed it. The project is a standard WinRT C++ component, generated using the Visual Studio template, but incorporating some of the code generated by the DirectX app template also. I changed a ref class to a non-ref class, and the fact that the non-ref class had  a member variable of type Platform::Array<byte>^ seemed to be an issue. Anyway, I just avoided including the member variable, maybe I'll revisit it to investigate further.

    This was all in the context of some memory exceptions I was getting that I've sorted out now. I think this was related to using an XMMATRIX as a member variable, which the documentation says you should avoid. But the Visual Studio-generated DirectX app puts such a member variable in the file CubeRenderer.h that it generates, albeit inside a struct. This was causing me no problems when the member variable was inside a ref class, but for my own purposes I changed the enclosing class to a non-ref class and I started getting occasional crashes. When I removed the member variable, everything worked fine.

    Robert

    Wednesday, July 11, 2012 6:20 PM

All replies

  • Hi,

    Yes, Not all the Win32 API can be used in metro.
    There is the list
    http://msdn.microsoft.com/en-us/library/windows/desktop/br205757.aspx

    If you want to load a DLL into metro, you can try Dynamic-Link Library Functions API instead of the old API.
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms682599(v=vs.85).aspx

    Best regards,
    Jesse


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, July 10, 2012 7:58 AM
    Moderator
  • Robert,

    It looks like you are referencing Win32 libraries/APIs in your code.  Is that the case?

    -Jeff


    Jeff Sanders (MSFT)

    Wednesday, July 11, 2012 3:21 PM
    Moderator
  • Jeff,

    I don't think so. I've resolved this now, but I did quite a bit of code reorganization, so I'm not sure exactly what fixed it. The project is a standard WinRT C++ component, generated using the Visual Studio template, but incorporating some of the code generated by the DirectX app template also. I changed a ref class to a non-ref class, and the fact that the non-ref class had  a member variable of type Platform::Array<byte>^ seemed to be an issue. Anyway, I just avoided including the member variable, maybe I'll revisit it to investigate further.

    This was all in the context of some memory exceptions I was getting that I've sorted out now. I think this was related to using an XMMATRIX as a member variable, which the documentation says you should avoid. But the Visual Studio-generated DirectX app puts such a member variable in the file CubeRenderer.h that it generates, albeit inside a struct. This was causing me no problems when the member variable was inside a ref class, but for my own purposes I changed the enclosing class to a non-ref class and I started getting occasional crashes. When I removed the member variable, everything worked fine.

    Robert

    Wednesday, July 11, 2012 6:20 PM