Umdhtools.exe: Vazamentos de como usar o Umdh. exe para encontrar memória

Traduções deste artigo Traduções deste artigo
ID do artigo: 268343 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

O utilitário de heap (UMDH) de despejo do modo de usuário funciona com o sistema operacional para analisar as alocações de heap do Windows para um determinado processo. Esse utilitário e outras ferramentas associadas a ele, são destinadas principalmente para Windows 2000 e Windows XP. Clique na Jogar botão para exibir a demonstração em fluxo de mídia.

Observação O vídeo é codificado com o codec ACELP ®, você precisa instalar o codec ACELP ® livre disponível em http://www.Acelp.NET/acelp_eval.PHP



Observação Porque o malloc função do módulo C Runtime (CRT) usa a omissão de ponteiro do quadro (FPO) na versão original do Windows Server 2003, você não poderá ver as informações de pilha completa da malloc função usando a ferramenta UMDH. Esse problema foi corrigido no módulo CRT do Windows Server 2003 Service Pack 1 (SP1). Portanto, você pode ver as informações de pilha completa da função malloc no Windows Server 2003 SP1.

Mais Informações

Antes de usar UMDH

Se você acha que você está enfrentando um vazamento de memória, lembre-se Se a memória vazamentos podem não ser o que aparecem. Você pode descobrir que um vazamento de memória não é um vazamento de memória verdadeira, mas é uma melhoria de desempenho. Para o exemplo, o mecanismo de banco de dados Microsoft Jet pode consumir grandes quantidades de memória (até 128 MB em um computador de 256 MB) porque ele recupera dados e grava armazena em cache. O cache permite que o Jet obter read-ahead rápida e write-ahead armazenamento em buffer.

Para determinar se ou não um processo está enfrentando memória vazamentos, use o Windows Performance Monitor (Perfmon. exe) e monitorar privado Bytes na categoria de processo para seu aplicativo. Bytes particulares é o total de memória que o processo alocou, mas não está compartilhando com outros processos. Observe que isso é diferente de Bytes virtuais, que também é interessante para monitorar. Bytes virtuais é o tamanho atual em bytes das espaço de endereço virtual que usa o processo. Um aplicativo pode causar o vazamento virtual memória, mas não poderá ver uma diferença nos bytes particulares que estão alocados. Se você não vir memória aumentar quando você monitorar bytes particulares, mas você suspeito que ainda estão em execução da memória, monitor de bytes virtuais para ver Se você estiver usando a memória virtual. Para obter informações adicionais sobre como detectar vazamentos de memória e a visão geral do Monitor de desempenho (Perfmon. exe) do Windows, visite o seguinte site da Microsoft:
http://msdn.microsoft.com/en-us/library/ms404355.aspx
Para certificar-se de que seu aplicativo está vazando memória, coloque o suspeita de código em um loop com muitas iterações e monitorar particular e bytes virtuais para qualquer aumentos de memória. Assista certificar-se de que o número. de bytes particulares e bytes virtuais não enfim permanecem as mesmas e o número paradas aumentando. Se houver um ponto em que a memória pára aumentando, (por exemplo, continuar suba indefinidamente) fazer não ver um vazamento de memória, mas é mais provável, você vê um cache que está chegando ao seu tamanho máximo.

Se você determinar que você vê um vazamento de memória, antes de você usar o UMDH, execute estas etapas:
  1. Instale o utilitário UMDH.
  2. Definir a variável de ambiente do caminho do sistema para incluir a pasta onde você instalou o UMDH.
  3. Defina a variável de ambiente _ NT_SYMBOL_PATH para o Microsoft o caminho do servidor de símbolos para que UMDH possa localizar o símbolo debug arquivos.
O utilitário UMDH está incluído com as ferramentas de depuração para Produtos do Windows no site da Microsoft:
http://www.microsoft.com/whdc/devtools/DDK/default.mspx
Baixe e instale o utilitário e defina o sistema de caminho variável de ambiente para o caminho onde as ferramentas de depuração foram instaladas.

Antes de usar o UMDH, você deve instalar os símbolos de depuração correto para os componentes de seu aplicativo e seu sistema operacional. Use o Microsoft. Servidor de símbolos para adquirir os símbolos de depuração para componentes do Microsoft. Para obter mais informações sobre o servidor de símbolos da Microsoft, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
311503Usar o servidor de símbolos da Microsoft para obter arquivos de símbolos de depuração
UMDH tenta localizar os arquivos de símbolo usando o Variável de ambiente _ NT_SYMBOL_PATH. O comando para definir o caminho de um prompt de comando pode ser semelhante à seguinte:
Definir _ NT_SYMBOL_PATH = SRV * c:\LocalSymbolCache
Para obter informações adicionais sobre como configurar a depuração simbólicas informações, consulte a seção "Símbolos de depuração", posteriormente neste artigo.

Depois de concluir essas etapas, você estará pronto para usar o utilitário UMDH.

Despejos de pilha de captura com UMDH

UMDH é um utilitário que Despeja as informações sobre o heap alocações de um processo. Essas informações incluem a pilha de chamadas para cada alocação, o número de alocações são feitas por meio dessa pilha de chamadas e o número de bytes que são consumidos por meio dessa pilha de chamadas. Por exemplo:
00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00053
           ntdll!RtlDebugAllocateHeap+0x000000FD
           ntdll!RtlAllocateHeapSlowly+0x0000005A
           ntdll!RtlAllocateHeap+0x00000808
           MyApp!_heap_alloc_base+0x00000069
           MyApp!_heap_alloc_dbg+0x000001A2
           MyApp!_nh_malloc_dbg+0x00000023
           MyApp!_nh_malloc+0x00000016
           MyApp!operator new+0x0000000E
           MyApp!LeakyFunc+0x0000001E
           MyApp!main+0x0000002C
           MyApp!mainCRTStartup+0x000000FC
           KERNEL32!BaseProcessStart+0x0000003D
				
Essa saída UMDH mostra que houve 21280 (0x5320) bytes alocados total de pilha de chamadas. As 21280 bytes alocados de 20 (0x14) Separe as alocações de bytes 1064 (0x428). A pilha de chamadas é dado um identificador do BackTrace00053.

Para produzir um arquivo de despejo de pilha alocações, você deve usar o utilitário Gflags. exe, que também está incluído com os produtos de Debugging Tools for Windows, para saber que o sistema operacional você deseja que o kernel para rastrear as alocações.

Suponhamos que você deseje Despejar o conteúdo de heap(s) para o Notepad. exe. Primeiro você deve ativar o rastreamento de pilha aquisição para o aplicativo que você deseja testar. Por padrão, esse recurso. não está habilitado. O comando para ativar esse recurso é o seguinte:
Gflags -i Notepad. exe + deve
O comando ativar o rastreamento de pilha para processos que são já em execução, mas permite o rastreamento de pilha para todas as execuções de futuras da Notepad. exe. como alternativa, você pode definir o sinalizador por meio do usuário GFLAGS interface (execute Gflags. exe sem quaisquer argumentos para obter a interface do usuário). Uso o -deve opção para gflags desabilitar o rastreamento de pilha quando estiver terminada a depuração.

Quando você define os sinalizadores de imagem por meio de Gflags. exe, e você configurar os símbolos de depuração, você estará pronto para iniciar o bloco de notas (o aplicativo que está usando o UMDH). Depois que o programa for iniciado, você deve Determine a identificação de processo (PID) do processo de bloco de notas que acabou de ser iniciado. O comando para isso é o seguinte:
tlist
Você pode localizar o PID a partir da saída do aplicativo TLIST. As informações de PID também podem ser obtidas do Gerenciador de tarefas. Suponha que o PID para o processo de bloco de notas que você acabou de ser iniciado é 124. Você pode usar o UMDH para obter um despejo de pilha com o seguinte comando:
Umdh - p: 124 - f:notepad124.log
Resultados: Você tem um despejo de pilha completa do processo no bloco de notas a Arquivo Notepad124.log. Este arquivo mostra todas as alocações que foram feitas e o callstacks em que as alocações foram feitas.

Usar o Umdh. exe para comparar UMDH Logs

Enquanto o arquivo de log UMDH contém informações valiosas sobre o o estado atual de pilhas para um processo, se você estiver preocupado com Localizando um vazamento de memória, talvez seja mais valioso para comparar as saídas dos dois logs e Descubra qual callstack obteve o maior crescimento entre os arquivos de despejo de dois. O utilitário do Umdh. exe ajuda a comparar dois logs UMDH para fornecer uma análise dos diferença entre eles. Assim que tiver dois logs capturados em diferentes intervalos, em seguida, você pode usar o seguinte comando:
UMDH dh1.log dh2.log > cmp12.txt
- ou -
UMDH -d dh1.log dh2.log > cmp12.txt
O -d opção de linha de comando informa UMDH para exibir no formato decimal em vez de hexadecimal. A saída do comando compara as diferenças da os registros de alocações entre os dois e fornece informações semelhantes a o seguinte:
+ (f110 - 9df0) 5320 3a alocações BackTrace00053 Total de aumento = = 5320
Para cada BackTrace nos arquivos de log UMDH, é uma comparação feita entre os arquivos de logs de dois. Neste caso que mostra o último arquivo de log é especificado no UMDH tinha de linha de comando 0xF110 de bytes alocados durante a primeira log na linha de comando UMDH tinha 0x9DF0 de bytes alocados para o mesmo BackTrace (pilha de chamadas). "5320" É a diferença no número de bytes alocados. Em Neste caso, havia mais bytes alocados entre os horários de 0x5320 que o dois logs foram capturados. Os bytes vem a pilha de chamadas é identificada por "backtrace00053".

A próxima etapa é descobrir o que há em que Backtrace. Se você abrir o segundo arquivo de log e procure por BackTrace00053, você pode encontrar algo que é semelhante à seguinte:
00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00053
           ntdll!RtlDebugAllocateHeap+0x000000FD
           ntdll!RtlAllocateHeapSlowly+0x0000005A
           ntdll!RtlAllocateHeap+0x00000808
           MyApp!_heap_alloc_base+0x00000069
           MyApp!_heap_alloc_dbg+0x000001A2
           MyApp!_nh_malloc_dbg+0x00000023
           MyApp!_nh_malloc+0x00000016
           MyApp!operator new+0x0000000E
           MyApp!LeakyFunc+0x0000001E
           MyApp!main+0x0000002C
           MyApp!mainCRTStartup+0x000000FC
           KERNEL32!BaseProcessStart+0x0000003D
				
Ao exibir a pilha de chamadas, você pode ver que o LeakyFunc função aloca memória por meio da biblioteca de tempo de execução do Visual C++ nova função de operador. Se você achar que o número de alocações cresce à medida que você tirar mais arquivos de despejo, você pode concluir que a memória não está sendo liberada.

A habilitação de rastreamentos de pilha

As informações mais importantes nos logs UMDH são os rastreamentos de pilha as alocações de heap. Você pode analisá-los para verificar se um processo de vazamentos de heap memória. Por padrão, esses rastreamentos de pilha não são adquiridos. Você pode ativar isso recurso por processo ou todo o sistema. Use o comando a seguir para habilitar a pilha todo o sistema de rastreamento:
Gflags - r + deve
Reinicie o computador após esse comando. Para cada processo a ativação, o comando é:
Gflags -i APPNAME + deve
Onde APPNAME é o nome do arquivo do executável, incluindo a extensão (para exemplo, exe, Lsass. exe). O comando ativar o rastreamento de pilha para um processo que está sendo executado. Portanto, para processos que não é possível Reinicie (por exemplo, serviços, lsass, winlogon), você deve reiniciar o seu teste computador.

Use os comandos a seguir para verificar as configurações têm foi definido em todo o sistema ou para um processo específico: todo o sistema:
Gflags - r.
Processo específico:
Gflags i - nome do aplicativo
Por padrão, a profundidade de rastreamento de pilha máximo é 16. Se você quiser Consulte callstacks mais profunda, você pode aumentar esse executando GFLAGS. Clique para selecionar Registro do sistemae digite uma nova profundidade na Máx. Profundidade de captura de rastreamento de pilha controle de edição. Clique em Aplicare então reinicie o computador.
IMPORTANTE: Se você estiver usando o Windows NT 4. 0 Service Pack 6, você deve usar Umdh_nt4.exe, em vez do Umdh. exe e você deve usar o Gflags -r comando para definir o rastreamento de pilha de todo o sistema. Certifique-se de que você Reinicie o computador. O rastreamento de pilha de Umdh_nt4 não funciona em um por processo com base no Windows NT versão 4. Ela deve ser definida para todo o sistema.

Símbolos de depuração.

Uma das etapas mais importantes para usar o UMDH é certificar-se que você tenha arquivos de símbolos de BOM (arquivo. dbg ou. PDB) para obter um rastreamento de pilha em boas condições. No mínimo, você precisa dos arquivos de símbolo de Kernel32.dbg e Ntdll.dbg. Você pode adquirir os símbolos de depuração adicionais que talvez seja necessário à medida que você saiba mais sobre quais componentes geram perda de memória. Para obter mais informações sobre como obter arquivos de símbolos de depuração para Microsoft componentes, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
311503Usar o servidor de símbolos da Microsoft para obter arquivos de símbolos de depuração
Para obter informações adicionais sobre como usar o Servidor de símbolos da Microsoft e como obter pacotes de símbolos do Windows, visite o site da Microsoft:
http://www.microsoft.com/whdc/devtools/DDK/default.mspx
Quando você compila componentes com o Visual C++, é importante que Você não tem o banco de dados do programa para editar e continuar selecionado para o C++. Opções do compilador. Em vez disso, selecione o banco de dados do programa. Para definir o caminho de símbolo Inicialize a variável de ambiente _ NT_SYMBOL_PATH para o caminho a ser usado. Você pode usar o servidor de símbolos da Microsoft para adquirir os símbolos para Microsoft componentes.
311503 Usar o servidor de símbolos da Microsoft para obter arquivos de símbolos de depuração
Siga estas etapas para definir o _ NT_SYMBOL_PATH variável de ambiente:
  1. No painel de controle, clique duas vezes em Sistema.
  2. Clique na Avançado guia e clique Variáveis de ambiente.
Ou você pode definir a variável de ambiente _ NT_SYMBOL_PATH um janela de comando antes de executa o UMDH.

OBSERVAÇÃO: Também incluir o caminho para os PDBs dos componentes do seu aplicativo. Por exemplo, defina o caminho para _ NT_SYMBOL_PATH à seguinte:
SRV*c:\Symbols*http://MSDL.microsoft.com/download/Symbols;c:\myapplicationssymbols
A primeira parte deste caminho aponta para o servidor de símbolos da Microsoft e os estados que os símbolos usados serão baixados a c:\Symbols. pasta. A parte que segue a ponto e vírgula é o caminho para os arquivos PDB (arquivos de símbolo) especificamente para o aplicativo vazando.

Invocar o UMDH

É o único parâmetro de linha de comando necessário para UMDH o -p opção que especifica o PID do processo do qual uma pilha despejo será obtido. O PID pode ser obtido usando o Gerenciador de tarefas ou o Programa tlist. exe. Para um comando semelhante ao seguinte, será possível o log despejada na saída padrão:
Umdh - p: PID
UMDH também exibe diversas mensagens informativas padrão erro, e, portanto, se você redirecionar a ele, misturada com o registro real. Para reunir as mensagens informativas UMDH em um arquivo, use o seguinte comando:
Umdh - p: PID 2>umdh.msg
Se você deseja coletar o log que será despejado por UMDH em um arquivo, Use um dos seguintes comandos:
Umdh - p: PID > umdh.log
- ou -
Umdh - p: PID-f:umdh.log
Esses comandos são equivalentes.

O log padrão que é obtido por UMDH contém uma enumeração de consumidores de pilha são classificados por contagem de alocação. Se, para fins de depuração, você também precisa de um arquivo de despejo de todos os dos blocos alocados com seus correspondentes rastreamentos de pilha, o -d opção pode ser usada:
Umdh - p: PID -d.
Se você usar esse comando, você pode ver o seguinte no UMDH arquivo de log:
Alocações de rastreamento BackTrace00046: 005F69A0 005F6150
Estes são os endereços de memória das alocações para que pilha de chamadas. Se o depurador é anexado ao processo, despejar o conteúdo da memória em que esses endereços para ver o que foi alocado.

Se o log contém muitas informações, pode ser limitado somente ao contagem de usuários grandes com a alocação acima de um certo limite. Use o comando a seguir:
Umdh - p: PID - t: limite
Todas as opções de linha de comando (por exemplo, -p, -f, -t, -d) podem ser especificados simultaneamente em qualquer ordem. A seguir está um exemplo de linha de comando mais difícil:
Umdh - p: 123 - t: 1000 - f:umdh.log -d
Esse comando despeja pilhas para que o processo com PID 123 em o arquivo Umdh.log. Ele Despeja apenas os rastreamentos de pilha dessa conta para mais de 1000 alocações e ele também Despeja os endereços dos blocos de pilha são alocados por meio de cada rastreamento de pilha.

Outra opção de UMDH útil é o -l opção. Isso faz com que números de linha e de arquivo a ser impresso na pilha de chamadas, sempre que possível.

Explicada da saída UMDH

Se você redirecionado o log para um arquivo (Umdh - p: PID-f:umdh.log), o conteúdo é semelhante ao seguinte, que foi obtido um processo em execução do bloco de notas:
UMDH: Logtime 2000-06-28 10:54 - Machine=MYMachine - PID=704
   *********** Heap 00270000 Information ********************
       Flags: 58000062
       Number Of Entries: 87
       Number Of Tags: <unknown>
       Bytes Allocated: 00008DF0
       Bytes Committed: 0000A000
       Total FreeSpace: 00001210
       Number of Virtual Address chunks used: 1
       Address Space Used: <unknown>
       Entry Overhead: 8
       Creator:  (Backtrace00007)
           ntdll!RtlDebugCreateHeap+0x00000196
           ntdll!RtlCreateHeap+0x0000023F
           ntdll!LdrpInitializeProcess+0x00000369
           ntdll!LdrpInitialize+0x0000028D
           ntdll!KiUserApcDispatcher+0x00000007
   *********** Heap 00270000 Hogs ********************
   000001A0 bytes in 0x4 allocations (@ 0x00000068) by: BackTrace00031
           ntdll!RtlDebugAllocateHeap+0x000000FB
           ntdll!RtlAllocateHeapSlowly+0x0000005B
           ntdll!RtlAllocateHeap+0x00000D81
           ntdll!LdrpAllocateDataTableEntry+0x00000039
           ntdll!LdrpMapDll+0x000002A4
           ntdll!LdrpLoadImportModule+0x0000010D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpInitializeProcess+0x000009DC
           ntdll!LdrpInitialize+0x0000028D
           ntdll!KiUserApcDispatcher+0x00000007

   000001A0 bytes in 0x4 allocations (@ 0x00000068) by: BackTrace00034
           ntdll!RtlDebugAllocateHeap+0x000000FB
           ntdll!RtlAllocateHeapSlowly+0x0000005B
           ntdll!RtlAllocateHeap+0x00000D81
           ntdll!LdrpAllocateDataTableEntry+0x00000039
           ntdll!LdrpMapDll+0x000002A4
           ntdll!LdrpLoadImportModule+0x0000010D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpInitializeProcess+0x000009DC
           ntdll!LdrpInitialize+0x0000028D
           ntdll!KiUserApcDispatcher+0x00000007
				
O log contém um despejo de cada pilha no processo. Neste exemplo, o log inicia com uma pilha no endereço 270000. Após alguns contadores globais para o heap, o log contém um dump em ordem decrescente de classificada de rastreamentos de pilha que são responsáveis pela maioria das alocações. Ao comparar a dinâmica do memória que são usados em diferentes momentos, você pode deduzir o que ocorreu no processo e se qualquer uso de pilha é semelhante a um vazamento.

Problemas que podem ocorrer ao usar o UMDH

Os erros mais comuns ao usar o UMDH ocorrem porque pilha rastreamento não está habilitado. Além disso, símbolos incorretos para Ntdll. dll evitar UMDH de em execução. Para os outros arquivos de símbolos, UMDH é executado, mas o arquivo de log contém a pilha rastreamentos que tem nomes de função, mas em vez disso, endereços relativos dentro de módulos. Um erro de terceiro distante está especificando um PID errado. A seguir. resultados de mensagem de erro ao tentar executar o UMDH para um processo que não tem rastreamento de pilha ativado:
C:\>UMDH - p: 1140 UMDH: Logtime 28 De junho de 2000 12: 43 - máquina = MyMachine - PID = 1140 conectando...Módulo enumeração completa. SymGetSymFromName (processo, ntdll!RtlpStackTraceDataBase, xxx) falha, Último_erro = 126 UmdhGetAddrFromName não foi possível encontrar o banco de dados de rastreamento de pilha ponteiro (ntdll!RtlpStackTraceDataBase). símbolos de Ntdll. dll estão incorretos; podemos deve ser capaz de ver não importar símbolos.
Use o seguinte comando para Verifique novamente as configurações para o processo que você está investigando:
Gflags -i APPNAME
Use o comando a seguir quando você confiar na pilha de todo o sistema rastreamento:
Gflags - r.
Esses comandos mostram a lista de sinalizadores definidos para o aplicativo. Observe que, no caso de rastreamento de pilha de todo o sistema, o recurso pode ser exibido como ativo, mas se você não reiniciaram o computador após a execução do Gflags - r + deve o comando, na verdade, não está ativado. Se você desejar saber todos o aplicativo que tenha o rastreamento de pilha ativado, você pode exibir a chave USTEnabled a seguinte chave do registro:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows CurrentVersion arquivo Opções de execução
Se você executar o UMDH em um processo de rastreamento de pilha ativado, mas o aplicativo não tiver reiniciado desde que você definir os sinalizadores, você pode receber a seguinte mensagem em seus logs:
Foi um rastreamento de pilha não salva para esta alocação (índice = = 0)
Se você executar o conjunto a correto caminho de símbolo ou os símbolos estão incorretos e executar o UMDH, você pode mensagem de erro no log. No entanto, você pode receber apenas incorreta ou callstacks enganosas. Para verificar se você tem os símbolos corretos, inicie o Depurador de sistema NTSD para um processo, por exemplo:
bloco de notas NTSD
Em seguida, no console do depurador, execute o LD comando para carregar as informações de símbolo para o módulo e o LM comando para listar os módulos têm seus símbolos carregados. Se o saída das LM comando mostra os símbolos de exportação carregados, os símbolos não são bons. IF Você tem símbolos PDB carregados, os símbolos estejam em boas condições. Você pode receber a seguinte mensagem de erro se você tiver especificado o PID de errado:
C:\>UMDH - p: 1000 UMDH: 28 de junho de 2000 Logtime 09: 45 - máquina = MyMachine - PID = 1000 conectando... Falha em OpenProcess, Último_erro = 0x57

Chamar UMDH a partir do Visual Basic

Ele pode ser útil, às vezes, um número de logs de despejo ao longo do tempo porque o vazamento talvez não seja muito notável em primeiro lugar. Por exemplo, se você suspeita de que seu aplicativo da Web Active Server Pages (ASP) está com vazamento de memória, pode ser útil escrever um componente COM no Visual Basic shells check-out para UMDH. Você pode então chamar aquele componente da sua página ASP.

O Veja a seguir alguns códigos do Visual Basic que chama UMDH e cria um arquivo de log que se baseia a hora atual:
Private Declare Function GetCurrentProcessId Lib "kernel32" () As Long
      Public Function GetProcessID()
      GetProcessID = GetCurrentProcessId()
      End Function  
   .
   .
   .
      Dim strTime As String

      Dim sProcID As String
      sProcID = GetProcessID()
      strTime = "MYLOG_" & Format(Now(), "hhmm")
     
      Shell ("C:\UMDH\umdh -p:" & sProcID & " -f:d:\logs\" & strTime & ".txt")
				

Usar o UMDH com Windows NT 4. 0 Service Pack 6a (SP6a)

O utilitário UMDH incluída com as ferramentas de depuração para Produtos do Windows não funciona no Windows NT 4. 0. Um executável auto-extraível (Umdhnt4tools.exe) é fornecido com este artigo e contém o seguinte ferramentas para ser usado com o NT 4. 0:
  • Umdh_nt4.exe e dbghelp. dll
    Este é o Windows NT 4. 0 Versão SP6 do utilitário UMDH.
  • Dhcmp.exe
    Esse utilitário é usado para comparar dois UMDH despejos para determinar onde uma memória possíveis vazam occurrs.
O arquivo a seguir está disponível para download no Download da Microsoft Centro:
Recolher esta imagemExpandir esta imagem
Download
Baixe agora o Umdhnt4tools.exe
Data de lançamento: 28 de agosto de 2002

Para obter mais informações sobre como baixar arquivos de suporte da Microsoft, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
119591 Como obter arquivos de suporte da Microsoft de serviços on-line
Microsoft examinou esse arquivo em busca de vírus. A Microsoft usou o mais recente software de detecção de vírus que estava disponível na data em que o arquivo foi publicado. O arquivo é armazenado em servidores com segurança avançada que ajudam a evitar qualquer alteração não autorizada no arquivo. Colocar o Umdh_nt4.exe e dbghelp. dll em uma pasta e, em seguida coloca primeiro na sua variável de ambiente PATH. Usar Umdh_nt4.exe em vez de UMDH.

Em um computador que esteja executando o Windows NT 4. 0, você deve usar Gflags. exe para definir o rastreamento de pilha de todo o sistema. Por exemplo:
Gflags - r.
Certifique-se de que você reinicie o computador. Rastreamento de pilha de Umdh_nt4 não funciona em uma base por processo no Windows NT versão 4. 0. Ela é definida para todo o sistema.

UMDH_NT4 é diferente de UMDH pelo fato de não Compare arquivos de log. Por exemplo, você não pode fazer o seguinte:
UMDH_NT4 dh1.log dh2.log > cmp12.txt
Em vez disso, você deve usar o utilitário de Dhcmp.exe que está incluído com neste artigo. O comando é semelhante à seguinte:
DHCMP dh1.log dh2.log > cmp12.txt

Propriedades

ID do artigo: 268343 - Última revisão: quarta-feira, 18 de maio de 2011 - Revisão: 1.0
A informação contida neste artigo aplica-se a:
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT Workstation 4.0 Developer Edition
Palavras-chave: 
kbdownload kbarttypeshowme kbfile kbgraphxlinkcritical kbhowto kbsample kbmt KB268343 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 268343

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com