Luis H Demetrio

HTTP could not register URL http://+:8000/

Luis Henrique Demetrio — Fri, 05 Oct 2012 00:45:00 GMT

Uma das principais mudanças de segurança implementada à partir do Windows Vista é o Controle de Conta de Usuário (UAC). Com o UAC habilitado, todas as contas de usuário, incluindo contas administrativas, são executadas com direitos de usuário padrão.

Quando um administrador faz logon, o Windows cria dois tokens de acesso separados para o usuário, sendo um token de acesso sem privilégios administrativos (token filtrado) e outro de acesso de administrador (token full). No momento em que um processo precisa ser executado com privilégio elevado, o Windows não utiliza o token filtrado para executar o processo e, sim, o token completo. Se o usuário for administrador, o Windows exibe a tela do UAC apenas para confirmar a troca do token. Caso contrário, o Windows solicita as credenciais de uma conta administrativa.

O resultado é que isso afeta execução de serviços web HTTP, pois escutar um determinado endereço HTTP é uma operação restrita para usuários com privilégios administrativos. Por padrão, cada caminho HTTP é reservado para uso do administrador do sistema. Por exemplo, ao realizar o debug dos serviços no Visual Studio, a exceção AddressAccessDeniedException é gerada no momento em que o serviço é iniciado caso não seja executado através de uma conta elevada.

Mensagem de erro:

HTTP could not register URL http://+:8000/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details).

Uma maneira de resolver o problema é executar o Visual Studio elevado. Outra opção é executar o prompt de comando como administrador e executar o comando a seguir para atribuir o namespace HTTP para a conta do usuário:

netsh http add urlacl url=http://+:8000/ user=MYMACHINE\UserName

*MYMACHINE deve ser substituído pelo nome do computador ou pelo domínio e UserName pelo usuário administrador. E a URL digitada deve corresponder a URL da mensagem de erro.

Ao executar o serviço novamente no Visual Studio a exceção não irá mais ocorrer.

Para maiores informações do comando netsh execute o comando “netsh http”.

Aplicação exibindo o erro Run-time error '20599': Cannot Open SQL

Luis Henrique Demetrio — Sat, 21 Jul 2012 00:57:00 GMT

Em um dos trabalhos de compatibilidade de aplicações com o Windows 7 me deparei com uma aplicação que gerava a seguite mensagem de erro quando tentava abrir um relatório do Crystal Report:

Run-time error '20599':

Cannot Open SQL

Resumindo o cenário, o cliente não tinha o código-fonte da aplicação, não tinha acesso ao Event Viewer do servidor da base de dados e não possuía manual de implantação da aplicação.

Como a mensagem de erro apenas informava que a aplicação não conseguia se comunicar com a base de dados, a saída foi reproduzir o problema e capturar a tráfego de rede através do Network Monitor (NetMon). O NetMon é uma ferramenta utilizada para diagnosticar problemas com a conectividade do servidor que permite capturar, visualizar e analisar o tráfego de rede e descifrar os protocolos de rede.

A comunicação entre a aplicação e o SQL Server utiliza o formato de comunicação Microsoft denominado pacote TDS (Tabular Data Stream). Uma vez estabelecida a conexão as mensagens TDS são usadas para a comunicação entre o cliente e o servidor. A figura a seguir ilustra um fluxo simplificado de comunicação para
TDS.

Para facilitar a análise dos dados coletados pelo NetMon filtrei apenas o protocolo TDS para reduzir o volume de informações coletadas (ProtocolName == "TDS"). Após aplicado o filtro a troca de pacotes fica bem fácil de ser analisada. Após aplicado o filtro fica fácil visualizar o fluxo ilustrado na figura anterior.

Através da figura abaixo é possível verificar que o servidor SQL está retornando (TDS:Response) o erro "falha de logon" após a aplicação tentar realizar o login na base de dados (TDS:Login7 - define as regras de autenticação para uso entre cliente e servidor).

A conclusão é que não havia incompatibilidade da aplicação com o Windows 7. O erro era decorrente da configuração incorreta da base de dados de uma fonte de dados ODBC utilizada pela aplicação. A aplicação funcionou corretamente após o cliente informar a base de dados correta.

Referência

Protocolos de rede e pontos de extremidade TDS

http://msdn.microsoft.com/pt-br/library/ms191220(v=SQL.100).aspx

Microsoft Network Monitor 3.4

http://www.microsoft.com/en-us/download/details.aspx?id=4865

Web Service com Lentidão gerando Timeout

Luis Henrique Demetrio — Wed, 18 Jul 2012 03:26:00 GMT

O cliente estava recebendo erro de timeout em algumas páginas da sua aplicação web. Coletamos um dump do processo w3wp.exe correspondente ao webservice utilizado pela aplicação web, pois o cliente garantiu que as páginas do site apenas realizavam chamadas para esse webservice.

O primeiro passo é carregar a extensão de depuração de código gerenciado Psscor2 que é utilizada para ajudar no diagnóstico de problemas em aplicações do Framework .Net, para as versões 2.0, 3.0 e 3.5 através do commando .load psscor2.

A extensão Psscor2 contém um comando muito útil chamado !aspxpages que mostra informações sobre várias requisições ASP.NET, o tempo de execução e as threads associadas com o System.Web.HttpContext que estavam sendo executadas no momento em que o dump foi coletado.

A figura a seguir exibe o resultado da execução do comando !aspxpages. Através do resultado podemos observar que o tempo médio de execução das requisições, no momento em que o dump foi tirado, era de aproximadamente 5 minutos. É possível observar também que essa tempo ultrapassa, na maioria dos casos, o tempo
estipulado de timeout.

Vamos analisar a thread 41, referente ao web service consultas.asmx, cujo tempo de execução no momento do dump era de 472 segundos (7 minutos).

O comando !clrstack permite verificar a pilha de chamadas da thread para verificar o que está sendo executado.

Através desse comando é possível verificar que a thread está executando o método ExecuteReader para popular um objeto SqlDataReader. Para obter maiores detalhes do que está sendo executado nós podemos executar o commando !dso (!dumpstackobjects) na thread 41 e analisar as informações do objeto SqlDataReader.

Agora que temos o endereço do objeto SqlDataReader (070dac1c) nós podemos obter maiores detalhes deste objeto através do comando !do (!dumpobject).

Observe na figura que o timeout (_timeoutSeconds) dessa conexão é de 600 segundos. O comando SQL que está sendo executado pode ser obtido executando o dump do objeto para o endereço 070daa34 correspondente ao objeto SqlCommand (_command).

Finalmente para obtermos maiores detalhes deste objeto é necessário executar o comando !do (!dumpobject) para o endereço 070da99c correspondente ao comando SQL.

Por se tratar de informação de cliente, não pude mostrar o nome da comando SQL, mas é possível verificar que se trata de uma procedure. Para esse caso, a procedure era a responsável pela lentidão do serviço.

Controle de Conta de Usuário (UAC) e o Mapeamento de Drives

Luis Henrique Demetrio — Mon, 16 Jul 2012 16:30:00 GMT

Esse é um problema bastante simples, mas que ocorre frequentemente quando a área de suporte vai realizar o troubleshooting na máquina do usuário.

Imagine o seguinte cenário: o UAC está configurado no nível padrão e o usuário possui um recurso de rede mapeado para, por exemplo, o drive Z.

Vamos supor que o suporte tente executar como administrador uma aplicação localizada no recurso Z que está apresentando problema para diagnosticar se o erro é decorrente da falta de acesso.

Quando o suporte executa a aplicação como administrador é gerado outro erro informando ue o mapeamento Z não existe. Entretanto, o mesmo mapeamento é exibido no Windows Explorer.

Exemplo

Abra o prompt de comando e mapeie a pasta Windows para o drive Z, através do comando subst Z: C:\Windows. Abra o Windows Explorer e observe que o drive Z está mapeado conforme esperado.

Execute agora o prompt de comando elevado (botão direito e executar como administrador). Observe que ao tentar acessar o drive Z (digite Z: e pressione enter) é exibida uma mensagem informando que o drive não existe.

Motivo

Quando um administrador faz logon, o Windows cria dois tokens de acesso separados para o usuário: um token de acesso sem privilégios administrativos (token filtrado) e um token de acesso de administrador (token full). Para maiores detalhes veja o artigo Controle de Conta de Usuário (UAC).

Quando recursos de rede são mapeados, eles estão associados a sessão de logon corrente para o token de acesso do processo atual. Isso significa que, se um usuário usa o prompt de comando (cmd. exe) juntamente com o token de acesso filtrado para mapear um compartilhamento de rede, o compartilhamento de rede não está mapeado para processos que são executados com o token de acesso total de administrador.

Solução

Existem duas maneiras de resolver esse problema, sendo a primeira duplicar o mapeamento da unidade de rede para o token elevado. Nesse caso, além do primeiro mapeamento é necessário realizar um segundo através do prompt de comando elevado (executado com privilégio administrativo).

A segunda opção (não recomendada e não suportada pela Microsoft) é configurar a chave EnableLinkedConnections no registro do Windows para compartilhar as conexões entre os tokens filtrado e de administrador (full). Após configurar essa chave,o LSA (Local Security Authority) verifica se existe outro token que está associado a sessão do usuário e se o recurso de rede está mapeado para o token. Caso o LSA determinar que existe o mapeamento para o outro token do usuário, ele adiciona o mapemanento para o token atual.

Siga os seguintes passos para configurar a chave EnableLinkedConnections:

1.Abra o Regedit.exe.

2.Localize a seguinte chave de registro: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

3.Crie uma nova subchave do tipo DWORD com o nome EnableLinkedConnections e com o valor 1.

4.Reinicie o computador.

Maiores detalhes em: http://support.microsoft.com/kb/937624

O Caso da Página ASP.NET Extremamente Lenta

Luis Henrique Demetrio — Thu, 28 Jun 2012 00:26:00 GMT

O cliente estava enfrentando um problema de lentidão em um dos seus sites. Os usuários não conseguiam navegar entre as páginas alegando que a página ficava “em branco” e depois gerava timeout.

Coletamos um DUMP no momento da lentidão para analisarmos a causa da lentidão.

Comandos Executados

.load psscor2

Esse comando é utilizado para carregar a extensão de depuração de código gerenciado Psscor2 que é utilizada para ajudar no diagnóstico de problemas em aplicações do Framework .Net, para as versões 2.0, 3.0 e 3.5.

!threadpool

No momento em que o DUMP foi coletado a quantidade de threads em execução era superior a metade do valor limite do pool de threads.

Através do resultado é possível verificar que o problema de desempenho não é decorrente do consumo de processamento.

!eestack –ee

Esse comando permite investigar o callstack das threads gerenciadas. Observe que a maioria das threads estavam executando os seguintes métodos:

Praticamente todas as threads estavam executando os mesmos métodos.

Através desse commando é possível analisar a pilha de chamadas não gerenciada dessas threads.

Observe que o callstack da thread acima mostra que ela está bloqueada por outra thread. O mesmo ocorre para a maioria das outras threads.

!syncblk

A figura abaixo mostra que a thread 156 está bloqueando (lock) as demais threads (348 no total).

A análise do callstack da thread 156 mostra que a ferramenta CA Wily Introscope é quem está controlando essa thread e não está liberando o LOCK.

O problema foi resolvido desativando o serviço CA Wily Introscope.

Serviço .NET Travando Intermitentemente

Luis Henrique Demetrio — Sun, 24 Jun 2012 21:24:00 GMT

Uma vez trabalhei em um caso onde um serviço intermitentemente parava de atender as requisições do System.Runtime.Remoting sem gerar nenhum log de erro.

O erro ocorria no ambiente de produção e a primeira ação tomada foi coletar um dump no momento do travamento.

Existem várias formas e cenários para coletar um dump. Nesse caso específico, o dump pode ser coletado através do gerenciador de tarefas do Windows. Na aba Processos do Gerenciador de Tarefas, localize o processo do serviço e clique em Create a dump file (ou criar arquivo de despejo).

Utilizamos o WinDbg para abrir e analisar o dump. O WinDbg é um User mode e Kernel mode debugger com uma interface gráfica que usa a infraestrutura dos debuggers NTSD, CDB e KD para prover um ambiente mais parecido com o Visual Studio, com janelas de watch, breakpoints visuais em linhas de código e outras facilidades, por exemplo, exibir variáveis (incluindo objetos C++), stack traces e memória.

Também utilizamos a extensão Psscor2 do WinDbg criada para ajudar no diagnóstico de problemas de alto consumo de memória, alto consumo de processamento, chashes, hangs e outros problemas que podem ocorrer em aplicações do Framework .Net, para as versões 2.0, 3.0 e 3.5.

Comandos Executados

.load psscor2

Esse comando é executado para carregar a extensão de depuração de código gerenciado Psscor2 que é utilizada para ajudar no diagnóstico de problemas em aplicações do Framework .Net, para as versões 2.0, 3.0 e 3.5.

!threads

Esse comando é utilizado para obter as informações de cada thread gerenciada do sistema incluindo a última exceção que foi gerada pela thread. O objetivo da execução desse comando é verificar quais eram as threads que estavam sendo executadas e se haviam exceções geradas pelas threads, conforme exibido a seguir:

Através do resultado acima é possível observar uma quantidade elevada de threads sendo executada (4007) e uma quantidade elevada de threads (4005) aguardando enfileirada.

!eestack –ee

Através desse commando é possível obter o call stack de todas as threads gerenciadas do processo. Ao analisar a pilha dessas threads é possível identificar que a maioria das 4000 threads estavam executando o método SerializeToDisk da classe RefDataCacheController, conforme exibido a seguir:

!threadpool

Esse comando é utilizado para exibir o estado do thread pool durante o momento em que o dump foi coletado. Através desse identificamos que a quantidade de threads utilizadas pela aplicação atingiu o valor máximo do limite disponível no ThreadPool, conforme exibido a seguir:

Além de todas threads do thread pool estarem ocupadas, havia uma fila de 36522 work items para serem executados pelo thread pool. Uma vez que o remoting utiliza o thread pool para atender as requisições remotas, o serviço não para de atender as requisições de remoting.

Através da execução dos comandos citados anteriormente foi possível identificar que o processo estava consumindo todas as threads disponíveis no thread pool e que essas threads executavam o método SerializeToDisk da classe RefDataCacheController.

Ao analisar o código-fonte da aplicação identificamos que esse método é executado a cada segundo através de um Timer (System.Threading.Timer) definido no construtor dessa classe. Nesse método existe um código responsável por desativar o timer visando garantir que apenas uma thread seja executada ao mesmo tempo e que não haja enfileiramento, conforme destacado no fragmento de código a seguir:

O fato da função responsável por desativar o timer ser executado dentro do lock (bloco responsável por garantir que apenas uma thread execute ao mesmo tempo) possibilita que mais de uma thread seja executada simultaneamente quando, por exemplo, houver uma demora na execução das duas funções que são executadas antes desse bloco. O intervalo de um segundo do timer mais o atraso na execução dessas funções permite que a primeira thread habilite o timer justamente após o momento em que a segunda thread desativa o mesmo.

É importante ressaltar que a classe System.Threading.Timer é thread safe, dessa forma, suas operações não precisam ser sincronizadas podendo ser removida dentro do lock.

A equipe de desenvolvimento foi alertada para rever a periodicidade ao qual o timer deve ser executado e alterar o método SerializeToDisk para que o método responsável por desativar a thread seja o primeiro a ser executado.

Como Determinar se o Usuário é Membro do Grupo Administrador no Windows 7 com o UAC habilitado

Luis Henrique Demetrio — Thu, 21 Jun 2012 17:58:00 GMT

Com o UAC habilitado no nível padrão, todas as contas de usuário, incluindo contas administrativas, executam com direitos de usuário padrão.

Quando um usuário faz logon no Windows, o sistema cria um token de acesso para ele. Esse token contém informações sobre o nível de acesso que é concedido ao usuário, incluindo os identificadores de segurança (SIDs) e privilégios do Windows. Quando um administrador faz logon, o Windows cria dois tokens de acesso separados para o usuário: um token de acesso sem privilégios administrativos (token filtrado) e um token de acesso de administrador (token full).

Para maiores detalhes sobre UAC veja o artigo: Controle de Conta de Usuário (UAC).

O UAC é um grande avanço para a segurança. No entanto, esse avanço quebra alguns paradigmas que você pode estar acostumado a usar para desenvolver aplicativos. Por exemplo, verificar se o usuário é administrador.

Se você utiliza a API IsUserAnAdmin do shell32 ou as classes WindowsIdentity e WindowsPrincipal do .NET Framework (veja o fragmento de código a seguir), você descobrirá que eles retornam verdadeiro quando o processo estiver elevado e falso caso contrário.

bool IsUserAdministrator()
 {
 WindowsIdentity identity = WindowsIdentity.GetCurrent();
 WindowsPrincipal principal = new WindowsPrincipal(identity);
 return principal.IsInRole (WindowsBuiltInRole.Administrator);
 }

O resultado está correto, entretanto, em alguns casos o valor não informa se o usuário é administrador independentemente se a aplicação está sendo executada elevada.

A API GetTokenInformation do advapi32.dll permite determinar qual é o token que o usuário está utilizando e com isso é possível assumir (isso mesmo, veja mais adiante) se o usuário é administrador independemente se o processo está ou não elevado.

[DllImport("advapi32.dll", SetLastError = true)]
 static extern bool GetTokenInformation(IntPtr tokenHandle, TokenInformationClass tokenInformationClass, IntPtr tokenInformation, int tokenInformationLength, out int returnLength);
 
 /// <summary>
 /// Passed to <see cref="GetTokenInformation"/> to specify what
 /// information about the token to return.
 /// </summary>
 enum TokenInformationClass
 {
 TokenUser = 1,
 TokenGroups,
 TokenPrivileges,
 TokenOwner,
 TokenPrimaryGroup,
 TokenDefaultDacl,
 TokenSource,
 TokenType,
 TokenImpersonationLevel,
 TokenStatistics,
 TokenRestrictedSids,
 TokenSessionId,
 TokenGroupsAndPrivileges,
 TokenSessionReference,
 TokenSandBoxInert,
 TokenAuditPolicy,
 TokenOrigin,
 TokenElevationType,
 TokenLinkedToken,
 TokenElevation,
 TokenHasRestrictions,
 TokenAccessInformation,
 TokenVirtualizationAllowed,
 TokenVirtualizationEnabled,
 TokenIntegrityLevel,
 TokenUiAccess,
 TokenMandatoryPolicy,
 TokenLogonSid,
 MaxTokenInfoClass
 }
 
 /// <summary>
 /// The elevation type for a user token.
 /// </summary>
 enum TokenElevationType
 {
 TokenElevationTypeDefault = 1,
 TokenElevationTypeFull,
 TokenElevationTypeLimited
 }
 
 
 bool IsUserAnAdministrator() {
 
 WindowsIdentity identity = WindowsIdentity.GetCurrent();
 WindowsPrincipal principal = new WindowsPrincipal(identity);
 
 // Verifica se o usuário tem a role de Admin. Caso tiver retorna verdadeiro.
 // Se o UAC estiver habilitado e o processo não estiver elevado a verificação abaixo retornará falso 
 //independentemente se o usuário pertencer ao grupo administrador
 if (principal.IsInRole(WindowsBuiltInRole.Administrator)) return true;
 
 // Se o processo não estiver executando a partir do Vista, não é necessário realizar a verificação do UAC.
 if (Environment.OSVersion.Platform != PlatformID.Win32NT || Environment.OSVersion.Version.Major < 6)
 {
 return false;
 }
 
 int tokenInfLength = Marshal.SizeOf(typeof(int));
 IntPtr tokenInformation = Marshal.AllocHGlobal(tokenInfLength);
 
 try
 {
 var token = identity.Token;
 var result = GetTokenInformation(token, TokenInformationClass.TokenElevationType, tokenInformation, tokenInfLength, out tokenInfLength);
 
 if (!result)
 {
 var exception = Marshal.GetExceptionForHR(Marshal.GetHRForLastWin32Error());
 throw new InvalidOperationException("Não foi possível obter a informação do TOKEN", exception);
 }
 
 var elevationType = (TokenElevationType)Marshal.ReadInt32(tokenInformation);
 
 switch (elevationType)
 {
 case TokenElevationType.TokenElevationTypeDefault:
 // TokenElevationTypeDefault - O usuário possui apenas um token, portanto não é administrador.
 return false;
 case TokenElevationType.TokenElevationTypeFull:
 // TokenElevationTypeFull - O usuário possui dois tokens e o processo está sendo executado elevado.
 return true;
 case TokenElevationType.TokenElevationTypeLimited:
 // TokenElevationTypeLimited - O usuário possui dois tokens mas o processo não está sendo executado elevado. 
 return true;
 default:
 // Não foi possível determinar qual o token do usuário.
 return false;
 }
 }
 finally
 {
 if (tokenInformation != IntPtr.Zero) Marshal.FreeHGlobal(tokenInformation);
 }
 
 }

Observe que essa técnica apenas detecta qual é o token que o usuário possui. Na maioria das situações, isso irá determinar se o usuário está executando como administrador. No entanto, existem outros tipos de usuários com permissões avançadas que podem gerar uma divisão de token durante um logon interativo (por exemplo, o grupo operadores de configuração de rede). Se você estiver usando um desses grupos de permissão avançada, esta técnica irá determinar o tipo de elevação e não a presença (ou ausência) de credenciais de administrador.

Se o UAC estiver desabilitado, a API irá retornar apenas o TOKEN TokenElevationTypeDefault. Caso o usuário estiver logado como administrador o nosso código de exemplo irá identificá-lo erroneamente como usuário comum. Por isso, nesse caso, é importante combinar os dois tipos de verificação (IsUserAnAdmin ou WindowsIdentity e WindowsPrincipal) com o TOKEN.

Para finalizar, a não ser que você realmente precise e saiba o que está fazendo, não utilize esses mecanismos de verificação. Caso você precise de direitos administrativos, crie, por exemplo, um manifesto para sua aplicação e defina que a aplicação precisa ser executada com privilégios administrativos.

No Visual Studio é possível definir essa configuração através do manifesto da aplicação localizado na pasta properties do projeto, conforme:

 <?xml version="1.0" encoding="utf-8"?>
 <asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <assemblyIdentity version="1.0.0.0" name="MyApplication.app" />
 <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
 <security>
 <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
 <!-- UAC Manifest Options
 If you want to change the Windows User Account Control level replace the 
 requestedExecutionLevel node with one of the following.
 
 <requestedExecutionLevel level="asInvoker" uiAccess="false" />
 <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
 <requestedExecutionLevel level="highestAvailable" uiAccess="false" />
 
 If you want to utilize File and Registry Virtualization for backward 
 compatibility then delete the requestedExecutionLevel node.
 -->
 
 <requestedExecutionLevel level="asInvoker" uiAccess="false" />
 </requestedPrivileges>
 <applicationRequestMinimum>
 <defaultAssemblyRequest permissionSetReference="Custom" />
 <PermissionSet class="System.Security.PermissionSet" version="1" ID="Custom" SameSite="site" Unrestricted="true" />
 </applicationRequestMinimum>
 </security>
 </trustInfo>
 </asmv1:assembly>

A tabela a seguir descreve os tipos de execução:

Nível de Execução	Descrição
asInvoker	Executa a aplicação com o token atual. Nunca solicita elevação.
highestAvailable	Tenta usar os direitos de usuário mais alto disponíveis. Solicitará o modo de aprovação de administrador caso o usuário for administrador.
requireAdministrator	Solicitará elevação, a menos que ser que o processo pai já esteja elevado.

Oracle Enterprise Manager 10g Grid Control no Windows 7

Luis Henrique Demetrio — Fri, 01 Jun 2012 21:18:00 GMT

Em um dos trabalhos de compatibilidade realizados, o cliente me informou que a ferramenta Oracle Enterprise Manager 10g só funcionava no Windows 7 quando executada com privilégios administrativos. Caso contrário, a aplicação era encerrada (Crash) após o usuário fornecer suas credenciais.

Informei ao cliente que por se tratar de uma ferramenta de terceiros, que o recomendado era acionar o fornecedor e solicitar o suporte até mesmo para evitar perder qualquer tipo de garantia do produto ou suporte.

Devido à urgência e aval do cliente, seguimos com o processo de troubleshooting.

O problema ocorria nas seguintes ferramentas: Enterprise Manager, Oracle SQL Plus e Oracle Export.

O seguinte erro era gerado no console do Enterprise Manager:

 Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x8077E76
 
 Function=[Unknown.]
 
 Library=C:\oracle\product\10.2.0\client_1\jdk\jre\bin\client\jvm.dll 
 
 
 Current Java thread: 
 at oracle.jdbc.driver.T2CConnection.t2cCreateState(Native Method) 
 at oracle.jdbc.driver.T2CConnection.logon(T2CConnection.java:346)
 at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:414) 
 at oracle.jdbc.driver.T2CConnection.<init>(T2CConnection.java:132)
 at oracle.jdbc.driver.T2CDriverExtension.getConnection(T2CDriverExtension.java:78) 
 at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:801)

No Oracle SQL Plus, através de um DUMP, identificamos que o seguinte erro ocorria após o CRASH:

sp2-1053 unable to initialize Oracle call interface

Já no Oracle Export a aplicação não exportava as tabelas e gerava o seguinte erro quando não era executada com o perfil de administrador:

 Export: Release 10.2.0.1.0 - Production on Sex Jan 6 14:26:07 2012
 
 
 Copyright (c) 1982, 2005, Oracle. All rights reserved.

 EXP-00056:
 
 EXP-00000: ExportaþÒo encerrada sem Ûxito

Causa do Problema:

Os processos da ferramenta Oracle Enterprise Manager 10g tentam criar um objeto de mapeamento de arquivo no namespace Global que requer o privilégio SeCreateGlobal, que não está disponível para usuários comuns.

O SHIM LocalMappedObject substitui o prefixo Global\ com o prefixo Local\ antes da aplicação chamar a API original.

Solução:

Habilitar o UAC (Controle de Conta de Usuário) no nível padrão recomendado pela Microsoft e criar os seguintes SHIMs (correções) para cada aplicação conforme descrito seguir.

Console do Enterprise Manager:

Utilize o SHIM LocalMappedObject para corrigir o problema.

O SHIM pode ser criado através da ferramenta Compatibility Administrator que faz parte do Microsoft Application Compatibility Toolkit 5.6 (ACT).

Ao executar o Enterprise Manager verificamos que o não se trata de um executável e sim de um arquivo .JAR.

Através do PROCMON foi possível obter a linha de comando utilizada para executar a ferramenta:

java -mx128m
 -DADMIN_WRL=C:\oracle\product\10.2.0\client_1\sysman\admin
 -Dsun.java2d.noddraw=true -DORACLE_HOME=C:\oracle\product\10.2.0\client_1
 -DGENERAL_BUS_PACK="" -DORBdisableLocator=true
 -Djdbc.backward_compatible_to_816=true 
 -cp
 "classes;jlib/oembase-10_1_0.jar;jlib/oemtools-10_1_0.jar;jlib/swingall-1_1_1.jar;jlib/ewtcompat-3_3_15.jar;jlib/ewt3.jar;jlib/ewt3-nls.jar;jlib/share.jar;C:\oracle\product\10.2.0\client_1\sysman\jlib\master.jar;C:\oracle\product\10.2.0\client_1\sysman\jlib\master_zh_CN.jar;C:\oracle\product\10.2.0\client_1\sysman\jlib\master_fr.jar;C:\oracle\product\10.2.0\client_1\sysman\jlib\master_de.jar;C:\oracle\product\10.2.0\client_1\sysman\jlib\master_it.jar;C:\oracle\product\10.2.0\client_1\sysman\jlib\master_ja.jar;C:\oracle\product\10.2.0\client_1\sysman\jlib\master_ko.jar;C:\oracle\product\10.2.0\client_1\sysman\jlib\master_pt_BR.jar;C:\oracle\product\10.2.0\client_1\sysman\jlib\master_es.jar;jlib/help4.jar;jlib/help4-nls.jar;jlib/oracle_ice5.jar;jlib/dbui2.jar;jlib/dbui2-nls.jar;jdbc\lib\ojdbc14.jar;jdbc/lib/nls_charset12.zip;jlib\orai18n.jar;jlib/kodiak.jar;sysman\jlib\netchart360.jar;jlib/javax-ssl-1_1.jar;jlib/jssl-1_1.jar;jlib/netcfg.jar;jlib/o3logon.jar;jlib/verifier14.jar;jlib/ewm-1_1.jar;jlib/ojpse_2_1_5.jar;network\jlib/netmgrm.jar;network\jlib/netmgr.jar;network/tools;lib\xmlparserv2.jar;jlib/cvd.zip;jlib/jndi.jar;jlib/jewt4.jar;jlib/jewt4-nls.jar;assistants/jlib/assistantsCommon.jar;jlib/jle2.jar;jle2-nls.jar;jlib/ldap.jar;jlib/ldapjclnt10.jar;rdbms\jlib\qsma.jar"
 oracle.sysman.vtx.vtxOemApp.OemApp console

O primeiro passo é executar a ferramenta Compatibility Administrator e clicar no botão FIX para criar o SHIM, conforme:

Nesse caso o SHIM deve ser aplicado na aplicação JAVA.EXE utilizada pela aplicação.

Através do arquivo de configuração da ferramenta, ou até mesmo pelo PROCMON, foi possível obter o caminho do arquivo JAVA.EXE utilizado pela aplicação.

Após fornecer o caminho do arquivo JAVA.EXE clique no botão NEXT.

A seguinte tela irá aparecer. Clique no botão NEXT para prosseguir.

Selecione o SHIM LocalMappedObject e clique no botão NEXT.

Clique no botão FINISH para finalizar.

Clique no ícone Salvar existe na barra de ferramentas (ou pressione CTRL+S) para salvar o SHIM (arquivo SDB).

Após salvar, clique com o botão direito no SHIM e clique no item Install.

Uma vez instalado é possível conferir através do nó Installed Database.

Uma alternativa para a instalação é executar o seguinte comando:

SDBINST.EXE <nome do SHIM (arquivo SDB)

Os mesmos procedimos foram realizados para o Oracle SQL PLUS e ORACLE EXPORT. Para o SQL PLUS o arquivo selecionado para criar o SHIM foi o sqldeveloper.exe e para o ORACLE EXPORT o arquivo foi o exp.exe.

Ferramentas:

Microsoft Application Compatibility Toolkit 5.6

Disponível em: http://www.microsoft.com/en-us/download/details.aspx?id=7352

Microsoft Application Verifier

Disponível em: http://www.microsoft.com/en-us/download/details.aspx?id=20028

Valores Atuais e Máximos de Paged Pool e Nonpaged Pool

Luis Henrique Demetrio — Mon, 23 Apr 2012 00:48:00 GMT

Existem duas áreas da memória do modo privilegiado (kernel), conhecidas como paged e nonpaged pools. O nonpaged pool é uma área de memória onde residem objetos que não podem ser escritos no disco, ou seja, enquanto eles estiverem alocados eles devem permanecer na memória física, ao contrário do paged pool, onde as informações podem ser armazenadas no pagefile.

É importante ficar atento à utilização dessas duas áreas de memória, observando o valor atual e o limite, pois quando o valor atual alcançar o limite, o sistema operacional ficará instável e irá gerar erros quando operações básicas forem realizadas.

O Performance Monitor (Perfmon) pode ser usado para exibir os valores atuais de memória disponível para Paged Pool e Non-Paged Pool através dos indicadores:

\Memory\Pool Paged Bytes

Mede o tamanho, em bytes, da área de memória onde residem objetos que podem ser escritos no disco quando não estão sendo usados. O Registry é o maior consumidor dessa área de memória.

\Memory\Pool Nonpaged Bytes

Mede o tamanho, em bytes, da área de memória onde residem objetos que não podem ser escritos no disco. Enquanto eles estiverem alocados eles devem permanecer na memória física. Os drivers dessa área de memória não podem ser interrompidos e aguardar por disco I/O.

Através do Process Explorer pode ser utilizado para visualizar os valores máximos desses indicadores, uma vez que não é possível obtê-los através do Perfmon.

Para visualizá-los no Process Explorer:

Abra o Process Explorer.
É necessário configurar os símbolos para que o Process Explorer exiba os valoreslimites de paged pool e nonpaged pool. Para tanto, clique em Options/Configure Symbols e verifique se a configuração dos símbolos corresponde a seguinte:
A localização da DLL do DBGHelp deve corresponder a DLL dbghelp.dll do Debugging Tools for Windows.
O caminho dos arquivos de símbolo deve ser: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Clique no menu View/System Information ou pressione CTRL+I.
Será exibida a tela com as informações do sistema que contém os valores atuais e os limites do paged pool e nonpaged pool, conforme exibido e destacado a seguir:

A tabela a seguir exibe os valores limites do Paged Pool e Non-Paged Pool:

Valor Limite	Efeito
0-50%	Informativo Comportamento normal.
60-80%	Atenção Uso quase crítico, que pode resultar na lentidão ou travamentos.
80-100%	Crítico Problemas de estabilidade e desempenho extremamente baixo para aplicações e serviços.

Maiores informações em:

Windows® Internals by Mark E. Russinovich and Alex Ionescu

Problemas de Automação no Internet Explorer 8.0

Luis Henrique Demetrio — Tue, 17 Apr 2012 03:08:00 GMT

Nessa semana me deparei com uma aplicação desenvolvida em Visual Basic 6.0 que gerava o seguinte erro quando a aplicação tentava navegar para uma página da Intranet para capturar informações do site:

-2147023179

Erro de automação (Automation error)

Interface desconhecida
(The interface is unknown).

Diagnóstico

Ao fazer o debug do código, foi possível identificar que o erro ocorria quando a aplicação tentava acessar os sites que pertenciam à zona da Intranet. Nenhum erro ocorria quando a aplicação acessava os sites associados à zona da Internet. Uma das diferenças entre essas zonas é que os sites da Intranet não possuem o Modo Protegido habilitado por padrão.

O modo protegido ajuda a proteger usuários contra ataques executando o processo do Internet Explorer com privilégios muito restritos. Quando executado no modo protegido, o IE8 é um processo de baixa integridade sem acesso de gravação a arquivos e chaves do registro.

O Internet Explorer 8 possui pelo menos dois processos (Figura 1) quando é executado em uma máquina que possui o UAC (Controle de Conta de Usuário) configurado no nível padrao. O processo do navegador (Frame Manager) e um ou mais processos (Tab Process) que podem ser executados nos seguintes níveis de integridade:

•Modo de Integridade Baixo (LowIL) para os sites de modo protegido

•Modo de Integridade Médio (MediumIL) para sites da Intranet/confiáveis

•Modo de Integridade Alto (HighIL) se o IE for iniciado como Admin

Figura 1 - Modelo conhecido como Loosely Coupled IE (LCIE)

O Internet Explorer 8 assume que o processo da aba padrão deve ser executado no modo de baixa integridade (LowIL). Dessa forma, quando o IE é criado via automação COM, a tab padrão é executada no modo de baixa integridade (veja o fragmento de código a seguir).

Dim IE As InternetExplorer
 
 
 Set IE = CreateObject("InternetExplorer.Application")
 
 IE.Navigate2 “http://intranet/”

Se o navegador determinar que a navegação requer que um processo (Tab Process) seja executado no modo de integridade média, o navegador faz a troca da aba virtual. O problema da automação ocorre porque o script ou código que criou a instância do Internet Explorer via automação permanece com uma referência anterior (irrelevante) para o processo da aba atual, ou seja, ele perde o controle.

Solução

A primeira solução é habilitar o modo protegido do Internet Explorer para os sites da Intranet.

Figura 2 - Habilitar o Modo Protegido para os sites da Intranet

Outra solução requer alteração no código da aplicação , conforme exibido no fragmento de código a seguir:

Dim IE As InternetExplorer
 
 Set IE = CreateObject("new:{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}")
 
 IE.Navigate2 “http://intranet/”

Ao utilizar o CLSID a aplicação cria uma instância do Internet Explorer no modo de integridade médio (MediumIL). A lógica é bem simples e pode ser verificada através da chave de registro HKEY_CLASSES_ROOT\CLSID\{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}\LocalServer32 que contém a REG_EXPAND_SZ com o
valor "%ProgramFiles(x86)%\Internet Explorer\iexplore.exe" –startmediumtab.

Fontes:

http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx

Compatibilidade Borland Quick Report 5 com Windows 7

Luis Henrique Demetrio — Sun, 15 Apr 2012 18:13:00 GMT

Em um dos trabalhos realizados para garantir a compatibilidade de aplicações no Windows 7, diagnostiquei uma aplicação que exibia apenas as duas primeiras de um relatório e que gerava o erro “Metafile is not valid” quando o usuário tenta navegar entre as páginas do relatório. A aplicação também ignorava a requisição de imprimir o relatório.

Com a ajuda do Process Monitor (PROCMON) foi possível identificar que o erro era decorrente de um OVERFLOW que ocorria quando a aplicação tentava armazenar o valor da variável de ambiente TMP. A aplicação espera o valor “C:\TEMP” ao contrário do valor “%USERPROFILE%\AppData\Local\Temp“ retornado pelo Windows 7.

Solução

Em cenários em que o cliente não possui o código-fonte, a solução é alterar o valor da variável de ambiente de usuário TMP de “%USERPROFILE%\AppData\Local\Temp” para “C:\TEMP”, conforme indicado abaixo:

Compatibilidade de Aplicações Visual Basic 6.0 no Windows 7

Luis Henrique Demetrio — Sun, 15 Apr 2012 18:11:00 GMT

Nos últimos trabalhos realizados para garantir a compatibilidade de aplicações no Windows 7, encontrei uma quantidade significativa de aplicações desenvolvidas em Visual Basic 6.0. O Visual Basic 6.0 apresenta alguns problemas de compatibilidade quando executado no Windows 7.

Os tópicos a seguir descrevem os problemas mais comuns encontrados durante o processo de migração das aplicações do Windows XP para o Windows 7.

1. Acesso Negado

O Process Monitor (PROCMON) é uma boa opção para diagnosticar as atividades do sistema de arquivos, do Registro e de processos e threads em tempo real. Na Figura 1 é possível verificar, através do PROCMON, que o erro de acesso negado ocorre devido à aplicação tentar gravar um arquivo texto no diretório da
aplicação localizado em C:\Program Files (x86). A partir do Windows Vista, é necessário ter privilégio administrative para realizar modificações por se tratar de um diretório protegido.

Figura 1 - Erro de Acesso Negado

Na maioria dos casos, esse problema ocorre devido o UAC estar desativado (prática não recomendada pela Microsoft). As aplicações VB6 são virtualizadas quando o UAC está habilitado. Consequentemente, com o UAC habilitado, o erro de acesso negado não irá ocorrer quando a aplicação tentar gravar o arquivo no diretório da aplicação, pois essa ação será automaticamente redirecionada (REPARSE) para a pasta VirtualStore localizada em %LOCALAPPDATA%, conforme ilustrado na Figura 2.

Figura 2 - Virtualização de arquivo para aplicações legadas

Para maiores detalhes sobre UAC consulte o artigo Controle de Conta de Usuário (UAC).

2. Permissão Negada

No Windows 7, o uso do método SendKeys gera o erro “Run-tine error '70': Permission denied” quando o UAC está habilitado. A Figura 3 exibe um DUMP coletado, para uma das aplicações diagnosticadas, no momento em que o erro ocorre. Através do DUMP é possível verificar que o erro ocorreu devido ao uso da função SendKeys:

Figura 3 - Permissão Negada devido o uso do método SendKeys

Um dos usos mais frequentes do SendKeys no VB6 é simular a tecla tab, conforme o exemplo a seguir:

Figura 4- Uso do SendKeys

Existem algumas soluções para esse corrigir esse problema sem a necessidade de executar a aplicação com privilégio elevado ou desativar o UAC. Sendo algumas delas:

Recompilar a aplicação VB6 no Windows 7. Esse problema de incompatibilidade foi corrigido na última versão do runtime do VB6 (MSVBVM60.DLL) que agora utiliza um método interno diferente para realizar a ação. Essa solução corrige o problema de acesso negado do código compilado, entretanto, não elimina o erro durante o debug do código através da IDE do VB6.

Substituir o SendKeys pela API PostMessage, conforme:

Public Declare Function PostMessage Lib "user32" Alias "PostMessageA" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long 
 
 Private Sub Text1_KeyPress(KeyAscii As Integer) 
 
 If KeyAscii = 13 Then 
 SendKeys "{tab}" '13 = Enter Key 
 PostMessage hwnd, &H100, &HD&, &H1C0001 
 End If 
 
 End Sub

3. Tipo Incompatível

Encontrei esse erro em algumas aplicações VB6. Observando apenas a mensagem de erro fica difícil identificar que o erro de incompatibilidade de dados ocorria devido à falta do runtime do VB5 (que possui como DLL principal a MSVBVM50.DLL)

Figura 5 - Mensagem Run-time error 13 Type mismatch

Em poucos casos a mensagem de erro informava corretamente que o motivo do erro era a falta da MSVBVM50.DLL.

Figura 6 - Mensagem de erro informando que o runtime do VB5 não foi encontrado.

O Process Monitor pode ser utilizado para confirmar que o problema realmente se refere à falta do runtime do VB5.

Figura 7 - Aplicação VB6 que possui dependência do runtime do VB5

O runtime do Visual Basic 5.0 funciona no Windows 7, apesar de não ser mais suportado, e está disponível para download no Centro de Download da Microsoft: http://support.microsoft.com/kb/180071.

4. ConnectionString Incorreta

A seguinte mensagem de erro é exibida quando a aplicação não é executada com privilégio de administrador:

Error: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified Code: 80004005 Source: Microsoft OLE DB Provider for ODBC Drivers

A mensagem equivalente no Windows 7 em português seria: Nome da fonte de dados não encontrado e nenhum driver padrão especificado.

Durante o debug da aplicação foi possível diagnosticar que a ConnectionString utilizada para retornar as informações de conexão estava incorreta, ou seja, retornava apenas o provider da conexão.

Valor retornado	Valor esperado
Provider=MSDASQL.1;	DRIVER=XX;SERVER=XX;DataBase=XX;UID=XX;PWD=XX;

O motivo do valor da conexão estar truncado ocorre devido um FIX de segurança que foi lançado a partir do Windows Vista. O objetivo do FIX é esconder as informações que expõem a segurança. É necessário adicionar na ConnectionString a informação “PersistSecurity Info=true” para que o ADO entenda que as informações sensíveis (Extended Properties) são necessárias e devem ser mantidas.

Links Úteis

Visual Basic 6.0 Resource Center - http://msdn.microsoft.com/en-us/vstudio/ms788229.aspx

Controle de Conta de Usuário (UAC)

Luis Henrique Demetrio — Sun, 15 Apr 2012 18:08:00 GMT

Introdução

O Controle de Conta de Usuário (UAC) é um conjunto de tecnologias de infraestrutura implantado no Windows Vista e aperfeiçoado no Windows 7 que é frequentemente mal-entendido pela maioria dos usuários.

A percepção comum é que o UAC é um recurso irritante e inútil cujo objetivo é perguntar se o usuário deseja realmente executar uma aplicação. Consequentemente, não é difícil encontrar em fóruns ou em sites de fornecedores a recomendação de desativar o UAC como solução para as aplicações que apresentam incompatibilidade com o Windows 7. Desativar o UAC é uma prática não recomendada pela Microsoft por expor a segurança do sistema operacional.

Objetivos do UAC

O UAC é destinado a permitir que os usuários executem aplicações sem o privilégio de administrador independentemente se o usuário possui esse privilégio. O objetivo é prevenir a instalação silenciosa de programas mal-intencionados e a infecção do computador.

O perfil de administrador permite alterar o estado do sistema, desativar o firewall, configurar a diretiva de segurança, acessar informações de outros usuários, instalar serviço ou driver que afete todos os usuários do computador e instalar softwares no computador inteiro. Os usuários comuns não podem executar essas tarefas.

O UAC executa a maioria dos aplicativos com direitos de usuário padrão, elimina a necessidade de direitos de administrador o tempo todo e encoraja os desenvolvedores de software a criarem aplicativos que executem com direitos de usuário padrão.

Mensagem de Notificação do UAC

A mensagem de controle de conta de usuário (Figura 1) não tem como objetivo perguntar se uma aplicação pode ser executada ou se pode realizar alguma ação. Essa mensagem é exibida para solicitar permissão para executar uma aplicação com direitos administrativos.

As solicitações de elevação são acionadas pelas atividades de usuário como instalação de aplicativos, alterações nas configurações do sistema ou ações que exigem privilégios administrativos.

Para os usuários com perfil de administrador, a mensagem oferece as opções de permitir ou negar que o aplicativo seja iniciado. Caso contrário, é solicitado o usuário e a senha de uma conta que possui perfil de administrador.

Figura 1 - Modo de aprovação de elevação exibido para os usuários com o perfil administrativo e comum respectivamente.

Com o UAC habilitado, todas as contas de usuário, incluindo contas administrativas, executam com direitos de usuário padrão.

Figura 2 - Visão Conceitual do UAC

O token de acesso do usuário padrão contém as mesmas informações específicas de usuário do token de acesso de administrador, mas sem os privilégios administrativos do Windows e os SIDs. Por padrão, esse token filtrado é usado para executar programas do usuário. O token não filtrado é associado apenas com programas elevados.

Virtualização

A maioria dos problemas de compatibilidade das aplicações legadas é decorrente da falta de privilégios para manipular informações em locais protegidos do sistema operacional. No Windows 7 é necessário ter o perfil de administrador para armazenar informações em locais globais do sistema, uma vez que essa ação afeta todas as contas de usuário.

Alguns aplicativos armazenam suas configurações em áreas globais do registro (HKLM\Software) ao invés de armazenar perfil do usuário (HKCU\Software), assim como, gravam configurações e logs nas suas próprias pastas, ou nas pastas de sistema (Windows, System32, Arquivos de Programas).

Uma boa prática recomendada pela Microsoft é salvar os dados específicos dos usuários no diretório %AppData% e salvar configurações dos usuários no perfil de registro do usuário (HKEY_CURRENT_USER\Software).

Com o UAC habilitado, quando um aplicativo legado tenta gravar em áreas protegidas do sistema de arquivos ou de registro, o Windows silenciosamente e transparentemente redireciona o acesso a uma parte do sistema de arquivos ou do registro que o usuário tem permissão para modificar. Isso permite que vários aplicativos necessários direitos administrativos em versões anteriores do Windows para executar com êxito usando direitos de usuário apenas padrão no Windows Vista e no Windows 7.

Figura 3 - Virtualização de Arquivos e do Registro

A virtualização de arquivos e registro pode ser configurada através da política de segurança “User Account Control: Virtualize file and registry write failures to per-user locations” ou através da chave do registro:

Key: SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Value: "EnableVirtualization" Data: 0 (disabled); 1 (enabled)

Quando o usuário navega em um diretório que contém arquivos virtualizados, o Explorer exibe um botão arquivos de compatibilidade na sua barra de ferramentas (Figura 4). Ao clicar nesse botão o usuário é redirecionado para o subdiretório correspondente ao VirtualStore da conta do usuário que contém os arquivos virtualizados.

Figura 4- Resultado da virtualização de arquivos

A variável de ambiente %LOCALAPPDATA% fornece o caminho do diretório VirtualStore correspondente a conta do usuário.a

Onde Armazenar as Informações

Requisitos	Informações Compartilhadas	Informações do Usuário
Visível no Explorer	%PUBLIC% (%SystemDrive%\Users\Public)	%USERPROFILE%\Documents
Oculto no Explorer e armazenado apenas localmente	%ALLUSERSPROFILE% (%ProgramData%, %SystemDrive%\ProgramData)	%LOCALAPPDATA% (%USERPROFILE%\AppData\Local)
Oculto no Explorer e que faz parte do perfil do usuário	n/a	%APPDATA% (%USERPROFILE%\AppData\Roaming)

Onde Configurar o UAC

Para configurar o UAC abra o Painel de Controle, clique em Contas de Usuários e clique em Alterar as configurações da Conta do Usuário (também é possível alterar as configurações através do link que é exibido no prompt de notificação do UAC).

Figura 5 - Configuração do Controle de Conta do Usuário (UAC)

É importante registrar que a Microsoft recomenda manter as configurações no UAC no nível padrão (Figura 5) e que é necessário reiniciar o Windows após ativar ou desativar o UAC para que as configurações tenham efeito.

Conclusão

Contas de usuário padrão proporcionam maior segurança e menor custo total de propriedade em ambientes domésticos e corporativos. Quando os usuários executam com direitos de usuário padrão em vez de direitos administrativos, a configuração de segurança do sistema, incluindo antivírus e firewall, é protegida. Isso fornece aos usuários uma área segura que pode proteger sua conta e o restante do sistema. Para implantações empresariais, as diretivas definidas por gerentes de TI da área de trabalho não podem ser substituídas e, em um computador compartilhado da família, diferentes contas de usuário são protegidas contra as alterações feitas por outras contas.

Referências
Security
Inside Windows Vista User Account Control
Mark Russinovich
http://technet.microsoft.com/pt-BR/query/4ce22051-1ff9-49c1-ab06-d97658e993e0