Сбой сертификации для приложения Магазина Windows с библиотекой на основе ATL

У меня есть библиотека Windows, разработанная на C ++, которая использует ATL коллекции, ATL CString и COM-интерфейсы с CComPtr. Я удалил все вызовы API, не разрешенные winrt, из библиотеки, и она прекрасно работает, поэтому я обернул библиотеку в C ++ / CX ref-class и пытаюсь использовать ее из приложения Магазина Windows. Приложение работает нормально, но сертификация приложения Win-Store не проходит со следующей ошибкой:

Обнаружена ошибка: тест поддерживаемых API обнаружил следующие ошибки:
API GetModuleHandleW в kernel32.dll не поддерживается для этого
Тип приложения. MyLibrary.dll вызывает этот API. API
InitializeCriticalSectionAndSpinCount в kernel32.dll не поддерживается
для этого типа приложения. MyLibrary.dll вызывает этот API.

Проект VS для моей библиотеки настроен для Магазина Windows со следующими параметрами:

Эти параметры активируют / деактивируют необходимые макросы (например, WINAPI_FAMILY как WINAPI_FAMILY_APP) в SDK.

Я на 100% уверен, что я не вызываю GetModuleHandleW или InitializeCriticalSectionAndSpinCount непосредственно в моей библиотеке, поэтому я подумал, что эта проблема возникла из-за метода некоторого класса ATL, который не был должным образом отфильтрован в Windows 8 SDK.

Погружаться в заголовочные файлы ATL было не очень полезно, так как все выглядит там правильно отфильтрованы, например, посмотрите этот фрагмент из ATL :: CComCriticalSection :: Init

#if !defined(_ATL_USE_WINAPI_FAMILY_DESKTOP_APP) || defined(_ATL_STATIC_LIB_IMPL)
if (!_AtlInitializeCriticalSectionEx(&m_sec, 0, 0))
#else
if (!InitializeCriticalSectionAndSpinCount(&m_sec, 0))
#endif

Чтобы доказать свою теорию, я взял hex-редактор и отредактировал GetModuleHandleW из моего файла Kernel32.lib, что дает мне следующую ошибку компоновки:

atls.lib (atlwinverapi.obj): ошибка LNK2001: неразрешенный внешний символ
__imp__GetModuleHandleW @ 4

Так что, похоже, моя теория не ошибается. Обратите внимание, что я делаю все это с помощью сборок релиза, так как отладочные сборки не проходят сертификацию.

Теперь вопрос:

Можно ли как-то точно узнать, какой класс внутри ATL саботирует мою библиотеку, кроме как посмотреть на заголовочные файлы?

Тот же вопрос в Форумы MSDN

Я добавил отчет об ошибках в Microsoft Connect с небольшим примером кода, который воспроизводит эту проблему.