August 2008 - Posts
No primeiro post da série eu apresentei alguns conceitos básicos de Debugging, como símbolos, processos e threads.
Neste novo artigo eu vou apresentar a área de trabalho do WinDBG, como iniciar uma sessão de debug e alguns comandos básicos para você se familiarizar com esta poderosa ferramenta.
Mas dessa vez com uma novidade: esta apresentação foi feita através de um screencast. Na minha opinião, post escritos são ótimos para assuntos teóricos, mas pecam um pouco quando se trata de assuntos extremamente técnico ou em apresentação de ferramentas. Por isso fiz esta nova versão, através de vídeo / audio.
Lembrando que a sua opinião é muito importante, com sugestões, críticas ou elogios.
Espero que gostem!
Download do vídeo (formato .wmv, 22 Mb, 16 minutos)
Obs.: Perto de 11:48' existe um corte apra agilizar o vídeo. Ficou um pouco estranho, desculpem! :)
Abraços.
-- André
Eu sou suspeito para falar, mas eu simplesmente sou fascinado por Debugging.
Seja no momento em que está codificando, ou depois que a aplicação já está em produção (o chamado postmortem debugging), é com debugging que os profissionais se irritam, ficam noites estudando, analisando, executando comandos e se superando. Descobrir a razão do erro ou da exceção e conseguir explicar até sua origem mais primitiva, dá uma sensação de ter o mais alto conhecimento do mundo da tecnologia.
Mas não se animem: isso dura só até o começo do próximo bug :(
Nesta série de artigos eu vou explicar a origem do debug, o significado e como realizar o debug utilizando ferramentas que não o Visual Studio 200X. O foco aqui é utilizar ferramentas mais poderosas, que possam levar o usuário até o stack, o heap, analisar as threads e leaks.
Além disso, vou apresentar também técnicas de análise de bugs, métodos para resolução de problemas, entre outras coisas não tão interessantes.
Afinal, o que é Debugging?
Debugging é o termo que tem a definição mais simples do mundo da tecnologia: remover bugs!
Não existe segredo. Debug serve para remover bugs, mais nada.
A questão é: quais são as melhores práticas para se conseguir isso? E em menor tempo? Como resolver tudo em menos de 1 hora? Alias, 15 minutos? Desculpa, 5 minutos!
Este é o cenário em que iremos trabalhar nestes posts.
Para resolver problemas complexos em pouco tempo, temos que conhecer ao máximo a estrutura da plataforma em que estamos trabalhando, a arquitetura do sistema, o que são processos, threads, handles, exceptions, first chance, ahhhh!
Debugging Tools for Windows
Nesta série de posts iremos utilizar o WinDBG, contido no Debugging Tools for Windows, disponibilizado gratuitamente pela Microsoft em http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx. No momento em que estou escrevendo este post, a última versão disponível é a 6.9.3.113. O que não faz a menor diferença se você se deparar com uma versão mais nova no link que passei. Todas as versões do WinDBG mantém a compatibilidade com versões mais antigas, e normalmente só adicionam recursos.
Para começar, faça o download da versão mais atual e instale-a.
O processo de instalação é extremamente simples e rápido. Além disso, você pode copiar e colar o diretório instalado na sua máquina em um pen drive, por exemplo. Os programas funcionarão perfeitamente (o que alias é uma vantagem muito grande, afinal, instalar Visual Studio em uma máquina de produção seria um pouco complicado certo :)).
Este pacote de ferramentas apresenta uma série de programas tão interessantes quando o WinDBG, e serão apresentados no decorrer desta série de posts. Mas no momento, nosso foco é na apresentação deste incrível programinha que irá mudar nossas vidas.
WinDBG, quem é você?
WinDBG é um user mode e kernel mode debugger com uma interface gráfica. Entendeu?
Tá bom, vamos voltar um pouco...
O que é User Mode e Kernel Mode?
Pense em seu sistema operacional com um divisão ao meio, criando duas partes. Uma parte é básica para o sistema e garante seu funcionamento, gerenciamento de memória e comunicação com hardware. A outra parte mantém os programas em execução, proprietários, maléficos, benéficos, aqueles e-mails estranhos, etc. Agora imagine se os programas tivessem acesso à parte do sistema operacional? Seria muito simples danificar o funcionamento da máquina, alterando comunicação com hardware, deletando arquivos básicos, influenciando na troca de context das threads, etc.
Por esse motivo, o Windows utiliza dois modos de acesso ao processador: user mode e kernel mode. As aplicações de usuário rodam em user mode, e o sistema operacional em kernel mode.
Kernel mode garante ao sistema operacional acesso a todos as memórias e instruções de CPU. User mode garante que as aplicações de usuário não irão afetar (pelo menos não de forma tão fácil) as instruções contidas em kernel mode, garantindo assim maior estabilidade e segurança para o sistema operacional.
Voltando ao assunto...
Explicações dadas, WinDBG é um user mode e kernel mode debugger. Nosso foco aqui é apenas User Mode, que é exatamente onde se concentram as aplicações desenvolvidas que iremos testar, assim como as threads que iremos criar, os objetos que iremos armazenar, etc. Além disso, para discutir kernel mode teríamos que ter muiitttooo mais espaço no servidor :).
Símbolos
Quando construímos aplicativos ou bibliotecas, os arquivos principais são gerados com o que chamados de arquivos de símbolos (symbol files). Estes arquivos são básicos para debugar qualquer tipo de processo. Nestes posts, todos os símbolos estão em arquivos com extensão PDB (Program DataBase), contendo normalmente informações como o nome e endereço de variáveis globais, nome de métodos e suas assinaturas, nome e locais de variáveis locais, tipos, números das linhas do códigos, entre outras.
Por conter estas informações importantes para analisar qualquer tipo de exceção, o debugger precisa encontrar estes arquivos de símbolos para dar a informação mais precisa e adequada. Por isso, é extremamente importante que a configuração de símbolos esteja correta. No momento certo vou informar como fazer isso e como gerar arquivos PDB dos programas criados da melhor maneira possível.
Processos e threads
Outra definição muito importante que precisamos ter antes de partir para a mão na massa é sobre Processos.
Um processo nada mais é do que um ambiente (armazenando recursos) para a execução de um programa.
Mais especificamente, um processo contém as seguintes informações:
- Um private virtual address space, que é uma série de endereços virtuais de memória que o processo pode usar;
- Um executável, representando o código inicial mapeado para o endereço virtual do processo;
- Uma lista de recursos do sistema, acessíveis a todas a threads do processo;
- Um contexto de segurança chamado access token que identifica o usuário, grupos de segurança e privilégios;
- Um identificador único chamado PID (process ID);
- Pelo menos uma thread de execução.
Já as threads (ou segmenos, como alguns livros traduzem, argh!) são as entidades que o Windows agenda para execução. Como citado acima, os processos precisam ter pelo menos uma thread de execução. Do contrário, os processos não irão executar nada!
Uma thread inclui os componentes listados abaixo:
- Uma série de registros representando o estado no processador;
- Dois stacks, um para excução enquanto estiver em kernel mode e outro enquanto estiver em user mode;
- Uma área de armazenagem local chamada de TLS (thread-local storage);
- Um identificador único chamado Thread ID;
- Algumas vezes contém o próprio contexto de segurança, principalmente em aplicações multithreaded.
Todas essas informações, agrupadas, formam o thread context.
Para a introdução já está de bom tamanho.
Instale o WinDBG e aguarde o próximo post da série, onde apresentarei a ferramenta e mostrarei um exemplo simples de debugging.
Espero que tenha gostado. Até lá!
-- André
Hoje fiz o exame 71-660, Windows Internals.
No geral gostei da prova. Ela cobre cenários reias no mundo do debugging, e não situações que nunca acontecem, como alguns outros exames.
As questões da minha prova foram divididas, aproximadamente, da seguinte maneira:
-
Ferramentas para Debugging (20%)
-
Desenvolvimento de Drivers (40%)
-
Commandos WinDBG (Kernel Mode e User Mode): 30%
-
Análise de problemas: 10%
No item de ferramentas para Debug, muitas questões abordavam qual era a ferramenta ideal para analisar um determinado erro.
Na parte de análise de problemas, algumas questões abordavam tópicos como “Se um usuário fala X, o que pode estar acontecendo na máquina?”.
Além deste itens, algumas poucas questões abordaram o Registry, as configurações nele para os serviços, etc.
Para fazer esta prova (agora mais comprovado do que nunca), você poderá utilizar os livros que indiquei neste post. Mas agora só quando a avaliação voltar, pois o período beta acabou.
Update: Não passei na prova, tirei 600 pontos. A parte de desenvolvimento de drivers me matou :( Com certeza vou tentar em breve.
Abraços.
-- André
Todos os produtos cadastrados no Commerce Server 2007 são baseados em uma definição. Esta definição determina quais propriedades estarão disponíveis para cada tipo de produto (ex.: televisão, CD, computadores, etc):
A product definition describes products in your catalog. It is a collection of properties that specifies the information that is stored for the product.
Uma vez cadastrado um produto associado a uma definição, não é possível alterar este relacionamento. Portanto, no Commerce Server, quando um produto é criado como uma televisão, por exemplo, ele sempre será uma televisão.
Isso parece extremamente óbvio em um cenário onde os cadastros de produtos não passam por um workflow de edição.
Imagine que duas pessoas diferentes são responsáveis pelo cadastro de um produto: um responsável por inserir os dados no Commerce Server e outro responsável por editar as informações e publicar o produto para venda:
Neste cenário, o primeiro passo é o cadastro básico de produtos. Este responsável não tem informações específicas do produto e, por esse motivo, o cadastro de TODOS os produtos é realizado com uma definição básica, DefinicaoBase, por exemplo.
O segundo passo é responsável por analisar o produto, inserir as informações específicas (que provavelmente vem de outra base), editar as existentes e publicar o produto após aprovação. A partir deste ponto, o produto tem uma definição específica, Televisao, por exemplo.
Este cenário não é atendido nativamente pelo Commerce.
Para realizar este processo utilizando os métodos / serviços disponibilzados, o produto tem que ser removido do Commerce e inserido com as mesmas informações, a não ser o tipo de definição.
Se levarmos em conta que catálogos com 80.000 produtos não são dificeis de serem encontrados, este processo teria um custo extremamente alto e lento, o que impactaria diretamente nos benefícios de se ter um ferramente como o Commerce Server 2007.
Solução Alternativa
Uma saída é desenvolver uma solução customizada, através de Procedures na base de catálogo e classes para acesso.
Como diria Jeff Lynch, Sometimes You Have to Write Some Code!
Antes de mostrar a solução, tenho que apresentar os problemas da outra abordagem:
1. O método para alteração de definição não tem lógica.
Temos que concordar que para alterar uma definição de um produto, não tem lógica removê-lo e adicioná-lo com as mesmas informações, a não ser a definição deste produto.
2. O processo é realizado via Agent.
Todo o processo de alteração (alias, remoção e criação) do produto é realizado via Agent, o que gera um impacto muito grande de performance quando pensamos em um número expressivo de produtos em um catálogo.
3. Muito suscetível a erros e inconsistências
Este processo possibilita que a transferência dos dados do produto a ser removido para o produto a ser criado (os mesmos ) gere inconsistências nos dados, já que não é difícil que as informações se percam no meio do caminho.
Portanto, o objetivo aqui é criar um mecanismo logicamente correto, com boa performance e que garanta a consistência dos dados, contando ainda com segurança e controle transacional.
A solução é simples:
- Criar uma procedure que faça a alteração de definição de um produto, fazendo todas as consistências necessárias;
- Criar classes para expor a procedure, além de efetuar controle de concorrência, transacão (além do Banco de Dados) e validações prévias;
- Criar serviços para expor esta funcionalidade através de Agents, assim como os web services do Commerce.
Por questões de apresentação, os códigos não serão expostos aqui neste post. Se você deseja obter os códigos-fonte para referência, entre em contato através do andre@nospam.andrenobre.com.br. (lembre-se de remover a palavra nospam no endereço).
Abraços!
-- André
Normalmente, cada site cadastrado no Commerce Server 2007 tem seus próprios recursos, seja Profile, Authentication, ou qualquer outro.
Porém, sites diferentes no Commerce podem compartilhar recursos, logo na instalação de um arquivo PUP.
Um cenário não muito raro é o compartilhamento da base de Profiles. Quando este configuração é realizada, dois ou mais sites do Commerce compartilham a mesma base de profiles, o que pode evitar duplicidade dos dados e centralizar o cadastro de clientes, entre outras informações.
Se você deseja compartilhar a base de profiles entre outros sites de Commerce, ao executar um UnPUP, siga todos os passos normalmente.
Ao chegar na tela Global Resource Pointers, certifique-se de escolher, no dropdown Existing global resources, o recurso existente que deseja reutilizar.
Apenas uma observação: ao reutilizar o recurso de profile, configure o novo site para também reutiliar o recurso CS Authentication do mesmo site do profile escolhido.
Abraços.
-- André
Se você deseja prestar o exame 71-660 (70-660 quando deixar de ser beta), pode começar por estes livros:
Não encontrei fontes que se relacionam diretamente a esta prova. Porém, existem diversos blogs que podem servir de base também para resolver dúvidas e apoiar os estudos:
Mais informações sobre a prova:
http://blogs.msdn.com/ntdebugging/archive/2008/07/10/windows-internals-beta-exam-70-600.aspx
Abraços
-- André
More Posts