为什么Finder打开/启动应用程序失败，当[NSWorkspace启动应用程序]将始终工作？

Question

我们有一台10.11版的MacBookPro。3已安装。我们用这台机器进行测试。这台机器出了问题，以至于我们的一个传统碳应用程序无法从Finder打开/启动。该应用程序坐在基座上并反弹，但从未启动。

然而，当从我们构建的可可注册实用程序使用[NSWorkspace启动应用程序]以编程方式启动完全相同的应用程序时，该应用程序将始终启动。

尝试使用活动监视器对这个失败的启动应用程序进行采样往往不会显示任何信息——除了挂起的应用程序似乎通常是在调用一个名为“cantTutThis”的函数。有人听说过这个吗？

（注：在我们所有的其他10.11.3系统，我们没有看到这个问题）（注2：没有消息出现在控制台，直到无响应的应用程序已经面临退出）

Call graph:
    2820 Thread_10759   DispatchQueue_1: com.apple.main-thread  (serial)
    + 2820 _dyld_start  (in dyld) + 71  [0x8fe06047]
    +   2820 dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*)  (in dyld) + 427  [0x8fe06231]
    +     2820 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*)  (in dyld) + 3514  [0x8fe0ac47]
    +       2820 dyld::initializeMainExecutable()  (in dyld) + 218  [0x8fe06f7f]
    +         2820 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&)  (in dyld) + 79  [0x8fe14ea1]
    +           2820 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&)  (in dyld) + 105  [0x8fe14c41]
    +             2820 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&)  (in dyld) + 296  [0x8fe14dae]
    +               2820 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&)  (in dyld) + 64  [0x8fe190a0]
    +                 2820 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&)  (in dyld) + 291  [0x8fe18f47]
    +                   2820 ???  (in OurCarbonApp)  load address 0x1000 + 0x7f9c24  [0x7fac24]
    +                     2820 ???  (in OurCarbonApp)  load address 0x1000 + 0x7f99b3  [0x7fa9b3]
    +                       2820 NSUnLinkModule  (in libdyld.dylib) + 81  [0x9a151346]
    +                         2820 NSUnLinkModule  (in dyld) + 344  [0x8fe10eae]
    +                           2820 __cxa_finalize_ranges  (in libsystem_c.dylib) + 318  [0x91779979]
    +                             2820 ???  (in CantTutThis)  load address 0x25f1000 + 0x2b0aec  [0x28a1aec]
    +                               2820 ???  (in CantTutThis)  load address 0x25f1000 + 0x8912d  [0x267a12d]
    2820 Thread_10773   DispatchQueue_2: com.apple.libdispatch-manager  (serial)
      2820 _dispatch_mgr_thread  (in libdispatch.dylib) + 52  [0x95eee2e2]
        2820 _dispatch_mgr_invoke  (in libdispatch.dylib) + 234  [0x95eee70e]
          2820 kevent_qos  (in libsystem_kernel.dylib) + 10  [0x9e123812]

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5):
        ???  (in CantTutThis)  load address 0x25f1000 + 0x8912d  [0x267a12d] [STACK TOP]        2820
        kevent_qos  (in libsystem_kernel.dylib)        2820

Binary Images:
    0x1000 -   0x70aff7 +com.writebros.OurCarbonApp (6.2 - 6.2.4.7) <0577AB86-2EC7-3C26-A6DA-B514FFF48D7C> /Applications/MMOurCarbonAppTest/OurCarbonApp.app/Contents/MacOS/OurCarbonApp
 0x25f1000 -  0x2991ff3 +CantTutThis (???) <44557A53-D8E2-33AB-BE43-94283F93AF19> CantTutThis
0x8fe05000 - 0x8fe3958f  dyld (0.0 - ???) <8F9518A3-884D-35FF-8FD9-FB149B7F1BF2> /usr/lib/dyld
(AND LOTS MORE BINARY IMAGES...)

Answer 1

我知道这是一条老线索，但对于上下文和未来的谷歌用户来说，这是一条新信息：这个应用程序受佩斯的iLok系统保护吗？

我有一堆受iLok保护的音频插件，所有这些插件都有“CantTutThis”的引用——可能是对试图解密包装/加密内容的黑客的恶作剧的点头。

我刚刚有一个在发布时崩溃的插件，崩溃的插件被识别为“CantTutThis”，大概是因为无法检索加密内容来报告实际的插件细节。