Como depurar uma falha de descarregamento de pacote de designtime que envolve uma falha no ThreadProc no Classes.pa

Não sei ao certo como rastrear a seguinte falha:

Acontece ao descarregar um pacote Designtime que é usado internamente na minha empresa. É o nosso código, portanto, é nosso erro corrigir, não um problema de fornecedor de componentes de terceiro

Parece que um thread está envolvido, mas, como acontece na Função ThreadProc em Classes.pas, acho que é um thread System / RTL simples, sem um wrapper de classe TThread que eu deveria procurar em nosso código. (Parte A da pergunta: é isso?)

A pilha de chamadas não contém nenhum código, apenas o próprio IDE e a função base na pilha de chamadas é ntdll.RtlInitializeExceptionChai

xemplo de pilha de chamada de violação de acesso em algum método TThread.Execute que mostra que o depurador não fornece detalhes sobre o encadeamento WHIC

 :7599b9bc KERNELBASE.RaiseException + 0x58
 :516b4965 ; c:\program files (x86)\embarcadero\rad studio\8.0\bin\exceptiondiag150.bpl
 :5003b058 NotifyNonDelphiException + $1C
 :77be6a8b ; ntdll.dll
 :77bb0143 ntdll.KiUserExceptionDispatcher + 0xf
 rtl.Classes.ThreadProc($CB9ED70)
rtl.System.ThreadWrapper($403E910)
:75fb339a kernel32.BaseThreadInitThunk + 0x12
:77bd9ed2 ntdll.RtlInitializeExceptionChain + 0x63
:77bd9ea5 ntdll.RtlInitializeExceptionChain + 0x36

Quando tento visualizar as informações do encadeamento, o segundo Delphi IDE que é o meu executável de destino trava, mas consigo continuar a exibir informações na minha instância do host de depuração delph

Estou ciente das técnicas para depurar pacotes de designtime e estou usando as técnicas mencionadas. Ou seja, tenho uma primeira cópia do delphi (BDS.exe) iniciando uma segunda cópia, porque o projeto do pacote definiu em seus Parâmetros de Execução, na caixa de edição do Aplicativo Host, o bds.exe principal do Delphi XE. C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\bds.exe). Portanto, quando executo meu pacote no modo de depuração, ele se carrega no Delphi ID

parte B da pergunta B é: Qual é o melhor local para definir um ponto de interrupção para que eu possa ver threads não-TThread, bem como segmentos baseados em TThread sendo criados? Se não há como definir um ponto de interrupção, que tal um meio alternativo de encontrar qual código está criando threads?

Update: Eu descobri que definir um ponto de interrupção na linha que lê Thread.Execute, na função ThreadProc, em Classes.pas, me dá um hit de ponto de interrupção em cada inicialização do TThread. Isso é suficiente para encontrar tópicos iniciados por um pacote de tempo de design ou tempo de execução de sua seção de inicialização, mas espero que exista uma maneira de nível ainda mais baixo para fazer iss

questionAnswers(1)

yourAnswerToTheQuestion