Search results for 'app:weblogs' matching tag 'Curiosidades'

Sobre el error "La operación solicitada requiere elevación" que puede devolver Runas.exe en Windows Vista/7

dmartin — Sat, 03 Oct 2009 05:00:00 GMT

En un foro que frecuento un usuario tenía el siguiente problema: Al intentar ejecutar como administrador un programa en Windows 7 usando el comando Runas.exe, le aparecía el siguiente mensaje de error:

740: La operación solicitada requiere elevación.

Ciertamente el usuario estaba proporcionando el nombre de usuario y la contraseña de un usuario con privilegios administrativos así que... ¿dónde estaría el problema?

En primer lugar, vamos a analizar con calma lo que quiere decir el mensaje de error. El mensaje de error "La operación solicitada requiere elevación" está recogido en el fichero de cabecera Ntstatus.h del SDK de Windows Vista y posteriores. Concretamente está definido con el nombre de macro ERROR_ELEVATION_REQUIRED.

¿Cuándo se devuelve ese código de error durante el funcionamiento de Windows?

En Windows los procesos se crean usando la API CreateProcess. Uno de los pasos que se siguen antes de crear un proceso en Windows Vista y posteriores es comprobar si el proceso en cuestión necesita elevar sus privilegios o no. A la hora de determinar este aspecto, entran en juego, entre otros, dos parámetros: El nivel de ejecución (runlevel) impuesto por el manifiesto de la propia aplicación, y el token del usuario que está lanzando ese programa. Existen tres posibles niveles de ejecución para una aplicación:

asInvoker: El nivel de ejecución es el mismo que el del proceso padre.
highestAvailable: El nivel de ejecución es el de mayores privilegios posibles, considerando el tipo de cuenta desde la cual se ejecuta el proceso.
requireAdministrator: El nivel de ejecución es administrativo, independientemente de las demás circunstancias.

Esta tabla recoge de forma básica las posibilidades:

Nivel de ejecución de la aplicación	Token del usuario	Requiere elevación o no
AsInvoker	Cualquiera	No
highestAvailable	Administrador "elevado"	No
highestAvailable	Administrador "estándar"	Sí
highestAvailable	Otro caso	No
requireAdministrator	Administrador "elevado"	No
requireAdministrator	Otro caso	Sí

Por administrador "elevado" me refiero a aquella cuenta con privilegios administrativos pero que, o bien ya ha elevado explícitamente sus privilegios (a través de un cuadro de UAC), o bien no tiene activada la característica Modo de aprobación del administrador (Admin Approval Mode). Esta característica se puede desactivar desde Directiva de grupo, pero yo personalmente lo desaconsejo. Un ejemplo de este tipo de cuentas es la cuenta "Administrador", creada durante la instalación del sistema operativo. Recuerde que el resto de cuentas con privilegios administrativos poseen dos tokens: uno limitado, con el que "actúan" por defecto, y otro "administrativo", que pueden aplicar si el usuario así lo indica a través de un cuadro de UAC.

Una vez que CreateProcess falla (devuelve un valor distinto de 1) y el último error se establece como ERROR_ELEVATION_REQUIRED (columna "Requiere elevación o no" de la tabla anterior), es asunto del proceso padre el tratar convenientemente este error. Si no lo hace, se registrará en Visor de sucesos, apartado dedicado a UAC, un evento informando de que el proceso padre no trató apropiadamente el error ERROR_ELEVATION_REQUIRED.

¿Qué ocurre cuando se lanza una aplicación desde la línea de comandos?

Imaginemos que el usuario intenta ejecutar el desfragmentador de disco de Windows 7 usando para ello una sintaxis de Runas.exe como esta:

runas /u:UsuarioAdministrador dfrgui.exe

Básicamente la línea de comandos detecta que no se trata de un comando interno, sino que se trata del programa Runas.exe, y por tanto se dispone a ejecutarlo usando CreateProcess. Como Runas.exe no es un programa que está marcado para requerir elevación de privilegios, CreateProcess retorna éxito.

Una vez que el planificador del sistema operativo cede el control al proceso Runas.exe recién creado, este se dispone a analizar su línea de comandos. Se encuentra con una petición de ejecutar Dfrgui.exe como si fuera el usuario administrador pasado como parámetro. Sin embargo, Runas.exe es poco más que un "envoltorio" de la API CreateProcessWithLogonW, que a su vez es poco más que un envoltorio de la API CreateProcess, pero pasando otro perfil de usuario distinto como parámetro.

Durante su ejecución, CreateProcess determina que Dfrgui.exe requiere privilegios administrativos (puesto que así se lo indica su manifiesto), y por ello devuelve falso y establace el último error como ERROR_ELEVATION_REQUIRED. Como Runas.exe es una herramienta que no está diseñada para tratar apropiadamente ese error, simplemente lo devuelve por pantalla de la forma "740: La operación solicitada requiere elevación".

Una vez desvelado el misterio, resta por comentar un aspecto que a estas alturas quizá ya se haya planteado:

¿Cómo es posible que ejecutando Dfrgui.exe desde la línea de comandos -sin usar Runas.exe- sí que aparezca un cuadro de UAC?

El secreto está en que la línea de comandos, antes de llamar a CreateProcess, informa al sistema de que va a tratar los posibles ERROR_ELEVATION_REQUIRED que puedan surgir. Esto lo consigue estableciendo unos atributos no documentados a la estructura STARTUPINFOEX, que se pasa como parámetro a la familia de API CreateProcess. Esto hace que no se registre el correspondiente error en el apartado UAC del Visor de sucesos. Seguidamente, la línea de comandos, sabiendo que se trata de un programa que debe elevar sus privilegios, lo intenta ejecutar mediante la API ShellExecuteEx. Esta API sí muestra el correspondiente cuadro de UAC, así que es la vía apropiada para ejecutar una aplicación que requiera privilegios administrativos.

En resumen, me gustaría resaltar estos puntos del tema del artículo:

En Windows Vista y Windows 7 la única forma de ejecutar algo con privilegios administrativos es mediante un cuadro de UAC. No vale con poner el nombre de usuario y la contraseña de un administrador en la línea de comandos.
Todo lo que se ejecute mediante la API CreateProcess, o alguna derivada de ella, no hará que aparezca un cuadro de UAC. Un ejemplo de ello es la utilidad Runas.exe.
Runas.exe, en Windows Vista/7, sirve para ejecutar una aplicación como si fuera otro usuario, pero no sirve para ejecutarla con mayores privilegios.
Si quiere que se ejecute una aplicación que requiere privilegios administrativos, use la API ShellExecuteEx, o alguna de sus derivadas. Esta API sí permite la aparición de un cuadro de UAC para que el usuario eleve sus privilegios.

¿Cuándo crea Windows un punto de restauración automático?

dmartin — Thu, 17 Sep 2009 05:00:00 GMT

Una de las dudas que más surgen entre los usuarios de Restaurar sistema es cada cuánto tiempo se creará un punto de restauración automático. Este artículo pretende dar una respuesta precisa a esta cuestión para así esclarecer aquellos casos en los que el sistema no haya creado un punto de restauración desde hace tiempo.

Windows XP

En Windows XP cada hora una tarea interna del Programador de tareas se encarga de analizar si el sistema está inactivo, es decir, si no está haciendo uso de la CPU ni del subsistema de E/S. Si se diera el caso, se realizan dos posibles comprobaciones para determinar si se debe crear un punto de restauración automático:

Si han pasado más de 24 horas desde el último punto de restauración, se crea uno automáticamente. Este parámetro (24 horas) es editable desde el Registro del sistema operativo, concretamente en la clave HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\SystemRestore, valor RPGlobalInterval.
Si la sesión actual de trabajo con el PC está durando más de X horas y el último punto de restauración es más antiguo, se crea un punto de restauración automático. Por defecto, esta configuración no está establecida, pero puede hacerlo desde el Registro en la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore, valor RPSessionInterval.

La comprobación de inactividad se realiza por defecto cada hora pero podría variar dependiendo de los valores de ciertas políticas de energía de su equipo. Eche un vistazo a los valores IdleTimeoutDc, IdleTimeoutAc de esta página de MSDN: http://msdn.microsoft.com/en-us/library/aa373239(VS.85).aspx. Aprovechando la inactividad, Restaurar sistema realiza otras tareas, tales como eliminar aquellos puntos de restauración cuyo tiempo de vida ya haya expirado, y de paso comprimir el almacén usando compresión NTFS. Estas tareas se realizan solo si el equipo está conectado a la corriente eléctrica, para evitar que se agote la batería en el caso de portátiles.

Si quiere profundizar en el funcionamiento de la herramienta Restaurar sistema de Windows XP, eche un vistazo a esta serie de artículos de mi antiguo blog:

http://rinconwindows.blogspot.com/2007/02/cmo-funciona-restaurar-sistema-parte-i.html

http://rinconwindows.blogspot.com/2007/03/cmo-funciona-restaurar-sistema-parte-ii.html

Windows Vista/7

En Windows Vista/7 el nuevo Programador de tareas muestra información detallada acerca de la tarea programada que crea un punto de restauración automático. Abra Programador de tareas, apartado \Microsoft\Windows\SystemRestore. La tarea SR tiene como desencadenantes:

El inicio del sistema.
Diariamente a las 12 AM.

En esos instantes se ejecutará el comando %windir%\system32\rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation.

El modificador /d de Rundll32.exe ya lo traté ligeramente en mi antiguo blog: Se trata de un modificador que le dice a Rundll32.exe "ejecuta este comando y no captures las posibles excepciones que ocurran". La función ExecuteScheduledSPPCreation es la encargada de verificar si el punto de restauración más antiguo tiene más de 12 horas (la mitad que en el caso de XP) y, si así fuese, creará uno nuevo.

Hay que tener en cuenta otras condiciones adicionales que puede observar en la pestaña Condiciones: El sistema debe estar inactivo durante al menos 10 minutos y además, en el caso de portátiles, debe estar conectado a la red eléctrica.

Espero que este artículo haya aclarado sus dudas con respecto a la creación automática de puntos de restauración por parte de Windows. En resumen, si su sistema no genera periodicamente puntos de restauración puede deberse a:

El servicio Programador de tareas no está iniciado.
El sistema no está inactivo durante los periodos de tiempo impuestos por Windows, según lo explicado anteriormente.

Sobre la nueva sintaxis del Panel de control en Windows Vista/Windows 7

dmartin — Fri, 11 Sep 2009 05:00:00 GMT

Quizá ya se haya dado cuenta de que en Windows Vista/Windows 7 algunos módulos del Panel de control que anteriormente estaban implementados en la clásica forma de un fichero .cpl ahora lo están en la forma de un fichero ejecutable (.exe). El motivo de este cambio es que con la introducción de Control de cuentas de usuario (UAC), se da el caso de que algunos de estos módulos requieren privilegios administrativos para ejecutarse. Veámoslo con un ejemplo:

El ejecutable DPIScaling.exe del directorio \Windows\System32 implementa la opción del Panel de control que permite cambiar la escala DPI del sistema. Este módulo requiere privilegios administrativos para ejecutarse, como así indica su fichero de manifiesto. Para verlo prácticamente, descargue Strings desde http://technet.microsoft.com/en-us/sysinternals/bb897439.aspx y abra una ventana de línea de comandos en el directorio donde la ha extraído. Introduzca este comando y pulse INTRO:

strings %SystemRoot%\System32\DPIScaling.exe | findstr /i requireAdministrator

La salida del comando, level="requireAdministrator", nos indica que el ejecutable en cuestión requerirá privilegios administrativos cuando lo invoquemos. Otros posibles valores para el atributo level son:

asInvoker: El ejecutable no requerirá privilegios administrativos.

highestAvailable: El ejecutable se ejecutará con los máximos privilegios que le permita la cuenta de usuario desde la que ha sido invocado.

Nombres canónicos en Windows Vista/Windows 7

Esta reestructuración de buena parte de los elementos del Panel de control trajo consigo una de las novedades que se introdujeron en Windows Vista y que se han mantenido en Windows 7: la posibilidad de abrir elementos del Panel de control usando un nombre canónico. Un nombre canónico es un nombre en inglés, no traducible, que describe de manera cercana al usuario el cometido de ese elemento del Panel de control. Esto evita que el usuario tenga que aprender el nombre de ficheros .cpl, muchas veces crípticos, y además permite separar el nombre del ítem de su implementación, ya sea en un clásico fichero .cpl o, ya sea en un fichero .dll o .exe.

Por ejemplo, para abrir el panel Agregar o quitar programas de Windows Vista/Windows 7, se puede usar esta sintaxis:

%windir%\system32\control.exe /name Microsoft.ProgramsAndFeatures

¿De dónde proviene ese nombre canónico, Microsoft.ProgramsAndFeatures?

Cuando el ejecutable Control.exe recibe el parámetro /name seguido de un nombre canónico, se invoca a la función IOpenControlPanel::Open, la cual en primer lugar busca el elemento correspondiente del Panel de control al que se está haciendo referencia. Cabe destacar que el Panel de control es un directorio virtual (no reside físicamente en el disco, sino que está implementado por el shell), situado en la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace. El valor (Predeterminado) de cada una de las subclaves de esa rama de Registro contiene el nombre con el que se mostrará en Panel de control (no el nombre canónico). Para encontrar la implementación de, digamos, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\{0DF44EAA-FF21-4412-828E-260A8728E7F1} (ítem de las propiedades de la barra de tareas y menú Inicio), se accede a la clave de registro HKEY_CLASSES_ROOT\CLSID\{0DF44EAA-FF21-4412-828E-260A8728E7F1}, en la cual existe un valor de registro de nombre System.ApplicationName y cuyo contenido es el nombre canónico: Microsoft.TaskbarAndStartMenu. Así pues, para abrir las propiedades de la barra de tareas y del menú Inicio ya sabemos que bastaría con ejecutar lo siguiente:

%windir%\system32\control.exe /name Microsoft.TaskbarAndStartMenu

Para ver qué es lo que realmente se ejecuta, eche un vistazo a la clave HKEY_CLASSES_ROOT\CLSID\{0DF44EAA-FF21-4412-828E-260A8728E7F1}\Shell\Open\Command.

Cada ítem del Panel de control puede implementar varias páginas

Podemos entender las páginas como subsecciones específicas del ítem del Panel de control. Para indicar una, debe usarse la sintaxis

%windir%\system32\control.exe /name Nombre_canónico /page Página

Veámoslo con un ejemplo:

Con los conocimientos que hemos adquirido, nos resulta sencillo determinar que el ítem Personalizar del Panel de control está implementado en la DLL Themecpl.dll. Es en esta DLL donde encontraremos información acerca de las posibles páginas de este ítem, en la forma, como no, de fichero XML.

Esta vez usaremos la aplicación gráfica Resource Hacker, que puede descargar gratuitamente desde http://www.angusj.com/resourcehacker/. Al abrir el fichero Themecpl.dll en esta aplicación, nos encontramos con dos ficheros XML adicionales al típico fichero de manifiesto (.manifest) que habíamos visto hasta ahora.

Este primer fichero XML especifica una serie de tareas que puede realizar el elemento del Panel de control "Personalizar". Estas tareas (cambiar los colores, el fondo de pantalla, etc.) se muestran como enlaces de texto justo debajo del elemento del Panel de control (suponiendo que esté configurado en la vista por categorías). Y lo que es más importante, estas tareas son indizables por el sistema de búsqueda de Windows Vista. Puede obtener más información en este artículo de MSDN: http://msdn.microsoft.com/en-us/library/bb776840(VS.85).aspx.

Esta segunda imagen hace referencia al segundo fichero XML, que es el que contiene la información acerca de cada una de las páginas que implementa este ítem del Panel de control. Entre las etiquetas <pagedefinition></pagedefinition> nos encontramos con una etiqueta <properties>, que hace referencia a cada una de las páginas. El atributo canonicalName nos ofrece su nombre canónico.

Como vemos, el ítem "Personalizar" del Panel de control admite como sintaxis:

%windir%\system32\control.exe /name Microsoft.Personalization /page pageColorization (para cambiar la configuración de color)

%windir%\system32\control.exe /name Microsoft.Personalization /page pageWallpaper (para cambiar el fondo de escritorio)

Ejercicio

Ahora que ya sabe cómo escudriñar en los ítems del Panel de control con el fin de construir accesos directos lo más directos posibles (valga la redundancia), le propongo como ejercicio que en un sistema Windows 7 averigüe la sintaxis para un acceso directo al Monitor de confiabilidad, que como sabe en Windows 7 está algo escondido dentro del Centro de acciones (Action Center).

Si se rinde, puede ver la solución seleccionando texto a partir de aquí: control.exe Microsoft.ActionCenter /page pageReliabilityView

Descubrir valores de Registro no documentados usando Process Monitor

dmartin — Sun, 16 Aug 2009 05:00:00 GMT

A mucha gente le gusta personalizar su sistema de escritorio al máximo posible. Por ello, Microsoft acostumbra a incorporar en sus sistemas operativos bastantes menús y cuadros de diálogo capaces de personalizar muchos de los detalles de funcionamiento de Windows. Sin embargo, hay ciertos detalles que no son modificables desde la interfaz gráfica, solamente desde el Registro; siempre siguiendo los pasos de algún artículo de la documentación oficial de Microsoft (KB, MSDN LIbrary, Technet Library, etc.). También hay detalles que no están documentados pero que pueden "descubrirse" utilizando herramientas de monitoreo del Registro, como Process Monitor, tal y como se explica en este artículo.

En el caso que nos ocupa, el usuario quería modificar el tiempo de aparición de la vista en miniatura de una aplicación en la barra de tareas de Windows Vista. En Windows Vista, la funcionalidad Windows Aero permite ver, a golpe de ratón, el contenido de todas y cada una de las ventanas minimizadas en la barra de tareas. El usuario intentaba buscar una forma de acortar ese tiempo de aparición de la vista en miniatura, pues le parecía excesivo. En Internet la alternativa que es más popular es la de modificar el valor de Registro MouseHoverTime de la clave de Registro HKEY_CURRENT_USER\Control Panel\Mouse. Sin embargo, este valor influye en el tiempo que tarda en reconocerse un posicionamiento del cursor del ratón, en cualquier parte de la interfaz gráfica de Windows. Era necesario buscar algún valor de Registro más específico, y para ello iba a recurrir a Process Monitor.

Antes de nada hay que comentar que no tenía la garantía de que existiera un valor de Registro que controlara ese aspecto tan específico de la interfaz gráfica de Windows. De existir, suelen ser parámetros que solo se tienen en cuenta en las versiones de depuración (checked) del sistema operativo. De todas formas, abrí Process Monitor y establecí un filtro de aquellos eventos de Registro que contuvieran en su ruta la palabra "Thumbnail". Inicié Explorer.exe y rápidamente me encontré con tres eventos bastante interesantes:

El primer evento indica el momento en que Explorer.exe examina una directiva, TaskbarNoThumbnail, configurable desde Directiva de grupo, encargada de desactivar las vistas en miniatura de la barra de tareas. La lectura de este valor me hizo pensar que los dos valores siguientes podrían estar relacionados con lo que buscaba.

Esos dos eventos siguientes hacen referencia a una búsqueda de cierta rama en el Registro (ExplorerThumbnails), tanto en la rama HKEY_CURRENT_USER como en la rama HKEY_LOCAL_MACHINE. El primer evento hace referencia al SID de mi usuario dentro de la rama HKEY_USERS (HKU) simplemente porque ejecuté Process Monitor desde una cuenta limitada, proporcionando obviamente el nombre de usuario y contraseña del administrador.

¿Qué sería esa rama ExplorerThumbnails? La verdad es que no encontré nada documentado en Internet, pero su nombre era lo suficientemente atractivo como para seguir indagando. Una de las cosas que suelo hacer en casos como este es crear la clave que busca en este caso Explorer.exe y ver qué valores o subclaves de Registro busca a continuación. Eso hice: Abrí Editor del Registro y creé la clave de Registro ExplorerThumbnails. Volví a capturar una traza con Process Monitor y el resultado ofreció otros tres valores tan interesantes como desconocidos:

Los valores InitialThumbnail, InitialTooltip y AutoPopTooltip me hacían pensar que efectivamente estaban relacionados con lo que realmente buscaba: Modificar el tiempo de aparición de la vista en miniatura. En este caso podría haber experimentado introduciendo algunos valores aleatorios para esos valores de Registro y observar los resultados, aunque en este caso recurrí a una lectura del código fuente de Explorer.

Al parecer, el valor InitialThumbnail tiene que ver con el tiempo en milisegundos que tarda en aparecer la vista en miniatura desde que se sitúa el cursor del ratón en la aplicación minimizada en la barra de tareas; InitialTooltip influye en el tiempo de aparición del texto emergente que siempre aparece encima de la vista en miniatura, un tiempo después. Por último, AutoPopTooltip influye en el tiempo que tarda en desaparecer el texto emergente. Por defecto, si no se encuentran esos valores en el Registro, el sistema supone, respectivamente, 500, 1000 y 5000 milisegundos.

Para concluir, codifiqué una aplicación gráfica que facilitara la modificación de estos valores en el Registro: http://winvista.mvps.org/Ficheros/TweakThumbnails.zip

Ya conoce otro posible uso de Process Monitor: Intentar descubrir valores de Registro (o ficheros) no documentados pero que pueden permitirnos configurar aspectos más o menos interesantes del sistema operativo.

Nota: Como indico en el margen izquierdo de este blog, toda la información que no está documentada por Microsoft es muy susceptible de cambiar e incluso de desaparecer en versiones posteriores de Windows. Este es el caso particular de esta rama del Registro, pues no es tenida en cuenta en Windows 7. Adicionalmente, deberá tomar las medidas oportunas si aplica este tip en un entorno de producción, pues de seguro se trata de un parámetro que no está tan probado como el resto de personalizaciones conocidas en el sistema operativo.

¿/Savecred, /Savedcred, /Savedcreds...? Es lo mismo

dmartin — Thu, 02 Jul 2009 05:00:00 GMT

Como quizá sepa, el comando Runas.exe de Windows XP y Windows Server 2003 sirve para ejecutar procesos en el contexto de otra cuenta de usuario. Los usuarios domésticos normalmente lo usan para ejecutar un proceso como administrador desde una cuenta limitada. Echando un vistazo al listado de parámetros de Runas.exe nos encontramos con uno que suele llamar la atención de bastante gente. Sirve para almacenar temporalmente en el administrador de credenciales (Credential Manager) el usuario y contraseña que va a ejecutar el programa. El atractivo de este parámetro es que no tendremos que introducir el nombre de usuario y contraseña para ese programa durante la sesión en curso. Sin embargo, no hay unanimidad con respecto al nombre del parámetro (incluso la propia documentación del sistema operativo creo que presenta alguna inconsistencia al respecto): Unos lo llaman /savecred, otros /savedcred, otros /savedcreds... Incluso en algunos sitios se indica que tienen semántica diferente.

Nada más lejos de la realidad. Runas.exe solo entiende el parámetro /sa (que contiene el mínimo número de letras que diferencian /savecred de los parámetros /smartcard y /showtrustlevels); lo que venga después le es indiferente. Del mismo modo, en cuanto se encuentra con /p supone el parámetro /profile; si se encuentra con /e supone /env, y así sucesivamente.

Nota: Por limitaciones del administrador de credenciales de XP Home Edition, el parámetro /savecred no es tenido en cuenta en esta versión de Windows. Este artículo no es aplicable tampoco a Windows Vista, pues el comando Runas.exe en Windows Vista es bastante diferente del de XP y será tema de un próximo artículo.

¿Qué hay detrás del mensaje "Win 16 Subsystem no tiene suficientes recursos..."?

dmartin — Thu, 06 Nov 2008 06:00:00 GMT

Si usa Windows XP es posible que en alguna ocasión se haya encontrado con el siguiente mensaje de aviso:

Win 16 Subsystem no tiene suficientes recursos para que continúe ejecutándose. Haga clic en Aceptar, cierre sus aplicaciones y reinicie su equipo.

¿Qué quiere decir exactamente este mensaje? Básicamente, es la consecuencia de una desacertada decisión de diseño que Microsoft tomó hace décadas y que provocó una serie de fallos descubiertos poco tiempo antes de la salida al mercado de Windows XP. Este artículo indagará un poco en este tema tan curioso.

Un poco de historia

Windows incorpora desde sus comienzos una interfaz que permite a los programadores diseñar elementos gráficos para sus aplicaciones. Esta interfaz recibe el nombre de GDI (Graphics Device Interface). Ya desde Windows 3.1, Microsoft supuso que GDI solamente podría generar handles de tamaño menor de 16 K. En aquellos tiempos, los handles se implementaban en el montón (heap) de GDI y estaban limitados a 14 de los 16 bits posibles. Es decir, los dos últimos bits estaban reservados (el último bit siempre era cero porque las direcciones de memoria tenían que ser pares). Con la llegada de los 32 bits, llegó GDI32 y con él los handles pasaron a ocupar una palabra de longitud: La mitad inferior contenía el valor en sí y la mitad superior una serie de bits para dar unicidad al handle.

Como supongo que ya sabrá, los sistemas operativos Windows de 32 bits incorporan un subsistema de 16 bits encargado de hacer funcionar aplicaciones antiguas de 16 bits. Este subsistema recibe el nombre de WoW (Windows on Windows). Obviamente, dicho subsistema tiene que tener alguna manera de convertir un handle GDI de 32 bits a uno de 16 bits y viceversa. Hasta la llegada de Windows XP lo que se había venido haciendo es simplemente descartar la mitad superior, quedarse con la mitad inferior y desplazarla dos posiciones hacia la izquierda. Como los handles eran menores de 16 K, el desplazamiento no suponía pérdida de información y todo funcionaba a pedir de boca... hasta que llegó Windows XP.

Con Windows XP empezaron los problemas

Con la llegada de Windows XP, surgió la necesidad de tener handles GDI de tamaño superior a 16 K. Por este motivo, el equipo de GDI decidió utilizar completamente los 16 bits de la parte inferior del handle (recuerde que hasta entonces solo se usaban 14 bits). El problema, como puede empezar a vislumbrar, sucedía cuando un handle de tamaño mayor de 16 K tenía que ser convertido por la máquina virtual de 16 bits. Al hacer el desplazamiento de los bits, ya sí se perdía información, y los efectos negativos no tardaron en aparecer.

Este problema se descubrió en una fase muy tardía de la beta de XP, por lo que Microsoft no tuvo otra opción que implementar rápidamente una solución temporal: Concretamente decidió que, antes de convertir, se comprobara el tamaño del handle; si éste fuese superior a 16 K, se mostraría el mensaje de aviso del principio de este artículo y se finalizaría la ejecución de la máquina virtual de 16 bits. La solución adoptada en Windows Vista y Windows Server 2008, ya con tiempo suficiente para comprobarla exhaustivamente, consiste en una tabla de correspondencias entre handles de 32 bits y handles de 16 bits.

Es curioso ver que una solución válida durante un determinado contexto temporal (desplazamiento de bits para convertir handles de 32 bits a 16 bits, y viceversa) puede ser totalmente errónea en el momento que se introduzca algún tipo de "ampliación" con la que no se contaba en ese momento. La implementación desde un principio de la tabla de correspondencias habría ahorrado un buen número de usuarios disgustados por la solución temporal.

Ya como curiosidad final, y esto ya es más una opinión personal, si se da cuenta, la cadena de texto en español contiene la nomenclatura inglesa ("Win 16 Subsystem"), cuando el resto de cadenas de Wow32.dll que hacen referencia a este concepto usan su acertada traducción al español, "Subsistema Windows de 16 bits". Ésta podría ser otra prueba más de que la implementación de esta solución temporal llegó muy, pero que muy tarde en el ciclo de desarrollo de Windows XP.

Avoiding access to base tables using Foreign Key, and two suggestions...

Eladio — Mon, 25 Aug 2008 05:00:00 GMT

Just a note before going further: I am going to maintain my blog in Spanish and English:

The English version will be hosted at msmvps.com (http://msmvps.com/blogs/eladio_rincon)
The Spanish version will be hosted at Solid Quality Mentors blog -- El Rincón del DBA (http://blogs.solidq.com/ES/ElRinconDelDBA).

Frequently, as a trainer and consultant I have to face in our clients the benefits that customers can get implementing DRI in their systems. I usually get different arguments such us:

If I don't define Foreign Keys, it is easier to perform bulk operations.
I prefer to validate the integrity in the Data tier instead of the database.
All the access to the base table is done using a set of stored procedures that I manage.
We prefer not implementing DRI because our data model changes very frequently, and it is complex to change the database logical design.

I could count many more cases apart of those four; from my experiencie, I think that generally the root cause is related to their ALM processes, and their best practices. Almost always, you can come up with a safer and better design solution; in fact, during the classes and the mentoring sessions, you convice them to go for the change, but days after, they come back to their daily work, and they do not have time to GO for the change.

Here is a good post from Conor Cunningham (http://blogs.msdn.com/conor_cunningham_msft/archive/2008/08/07/foreign-keys-are-our-friends.aspx) showing a hidden benefits of using DRI that you may not know: Using DRI SQL Server Optimizer, may dedice not to access base tables because SQL Server already knows -- due to the DRI -- that if a row exist child table, it must exists one in the parent table.

However, I would like to make some suggestions in this matter, that you may see useful.

Using a very similar script to Conors':

use AdventureWorks2008;
go

drop table f1
drop table t1
go

create table t1(id int, v char(1) default 'a'
, constraint t1_pk primary key (id))
go

create table f1(f_id int identity, t_id int not null, v char(1) default 'a'
, constraint f1_pk primary key (f_id)
, constraint fk1 FOREIGN KEY (t_id) REFERENCES t1(id))

create nonclustered index nci_f1_t_id
on f1 (t_id)

declare @i int=0
set nocount on
while @i < 2000
begin
insert into t1 (id) values (@i)
insert into f1 (t_id) values (@i)
insert into f1 (t_id) values (@i)
insert into f1 (t_id) values (@i)
set @i+= 1
end

Conor pointed in his post, those two queries does not need to access the base table -- as you can see in the execution plan:

/*
|--Index Scan(OBJECT:([AdventureWorks2008].[dbo].[f1].[nci_f1_t_id]))
*/
select f1.*
from t1 inner join f1
on t1.id = f1.t_id

/*
|--Index Scan(OBJECT:([AdventureWorks2008].[dbo].[f1].[nci_f1_t_id]))
*/
select f1.* from f1 where
exists (select * from t1 where t1.id = f1.t_id)

And I'd like to suggest to the SQL Server Team considering those two cases as well:

/*
|--Nested Loops(Inner Join)
     |--Clustered Index Seek(OBJECT:([AW].[dbo].[t1].[t1_pk]), SEEK:([AW].[dbo].[t1].[id]=(1)) ORDERED FORWARD)
     |--Nested Loops(Inner Join, OUTER REFERENCES:([AW].[dbo].[f1].[f_id]))
          |--Index Seek(OBJECT:([AW].[dbo].[f1].[nci_f1_t_id]), SEEK:([AW].[dbo].[f1].[t_id]=(1)) ORDERED FORWARD)
          |--Clustered Index Seek(OBJECT:([AW].[dbo].[f1].[f1_pk]), SEEK:([AW].[dbo].[f1].[f_id]=[AW].[dbo].[f1].[f_id]) LOOKUP ORDERED FORWARD)

*/
select f1.* from
t1 inner join f1
on t1.id = f1.t_id
where f1.t_id = 1

/*
|--Merge Join(Inner Join, MERGE:([AW].[dbo].[t1].[id])=([AW].[dbo].[f1].[t_id]), RESIDUAL:([AW].[dbo].[f1].[t_id]=[AW].[dbo].[t1].[id]))
|--Clustered Index Scan(OBJECT:([AW].[dbo].[t1].[t1_pk]), ORDERED FORWARD)
|--Index Scan(OBJECT:([AW].[dbo].[f1].[nci_f1_t_id]), ORDERED FORWARD)
*/
select t1.id, f1.*
from t1 inner join f1
on t1.id = f1.t_id

The first query, implements a typical OLTP query looking for all the detail rows for a given parent. In this example, SQL Server already knows that for each row in the child table (f1), at least exists one row in the header (t1). The only difference with the first query from Connor's post is the predicate, that I think fires the behaviour. In my humble opinion, the filter is highly selective, and then sets the t1 table in best position to be seek"ed".

The second query, seems to be a bit awkward, because SQL Server already knows that t1.id = f1.t_id. Why accessing t1 table, if the matching values are already in f1.t_id?

If you think that those last "logical suggestions" to avoid accesing parent tables should be considered by SQL Server, please, go to Conect and cast your vote (https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=363429).

Cerrar Explorer sin cerrar la sesión

dmartin — Mon, 11 Aug 2008 05:00:00 GMT

Completando la información del artículo anterior sobre Explorer, dejo por aquí un "truco" que quizá no conozca: En Windows Vista, al abrir el menú Inicio, pulsar simultáneamente las teclas Ctrl y Shift (Mayúsculas) y hacer clic con el botón derecho sobre una región libre del menú, nos aparecerá una opción adicional a la ya clásica "Propiedades": "Salir de Explorer". Esta opción es especialmente útil cuando haya realizado algún cambio en la configuración que requiera de un reinicio del explorador para que surta efecto. Hasta ahora quizá lo que haya hecho es "matar" al proceso Explorer.exe usando Process Explorer, con todos los riesgos que conlleva el "matar" a un proceso. La opción "Salir de Explorer" realiza los pasos correctos de cierre del explorador, que incluyen, entre otras cosas, el almacenar en el Registro del sistema ciertas configuraciones residentes en memoria. Al "matar" al proceso estas configuraciones se pierden irremediablemente.

Lamentablemente, esta opción no está presente en Windows XP y anteriores, por lo que tendrá que, como mínimo, reiniciar la sesión para lograr un efecto similar en esos sistemas.

Acabando con los mitos: Memoria usada por bases de datos (Database Snapshot)

Eladio — Tue, 04 Dec 2007 06:00:00 GMT

Hace unos días, vimos que independientemente de la base de datos desde la que se accedía a la información, las páginas leídas no se duplicaban en el buffer cache. Sin embargo, ¿qué pasa con Database Snapshot? ¿Funcionará igual?

Pequeña introducción a Database Snapshot (DBS).

Lo que DBS nos aporta es una vista de la base de datos en un instante determinado (cuando se creó). Lo que hace por debajo SQL Server, es que cuando el usuario necesita información de la BD DBS:

Si los datos NO se han modificado desde el momento de la creación de la DBS, leerá la información de la BD original.
Si los datos SI se han modificado desde el momento de la creación de la DBS, leerá la información de la DBS combinándola con la información de la BD original: por ejemplo, una tabla que en el momento de la creación del snapshot tenía 5 filas, y en el momento actual tiene 3, para consultar el estado de la tabla en el estado original leerá 3 filas de la BD original + 2 filas de la BDS.

Veamos cómo funciona internamente más allá de la explicación conceptual; Primero crearemos una tabla grande en la base de datos Adventureworks con el siguiente script (tabla con 1 millón de filas):

use Adventureworks
go

if exists (select * from sys.tables where name = 'tabla_1Millon_filas')
drop table tabla_1Millon_filas
go

create table tabla_1Millon_filas (
id1 bigint identity primary key
, relleno char(50) default 'a'
, v char(1) null)
go

-- insertar 1.000 x 1.000 = 1.000.000 filas
declare @i int
set @i=1
while @i<=1000
begin
insert tabla_1Millon_filas (v)
select top (1000) null
from Sales.SalesOrderHeader
set @i=@i+1
end

select count(*) [cantidad] from dbo.tabla_1Millon_filas

A continuación crearemos el snapshot; para ello ejecutaremos la siguiente instrucción:

if exists (select name from sys.databases
where name = N'DBS_Adventureworks')
drop database DBS_Adventureworks
go

-- create the snapshot database
create database DBS_Adventureworks on (
name = Adventureworks_Data,
filename = 'c:\program files\microsoft sql server\mssql.1\mssql\data\dbs_Adventureworks.ss' )
as snapshot of Adventureworks;

A continuación, borraremos de la base de datos original (Adventureworks), las 10.000 primeras filas:

-- borrado de 10.000 filas
use Adventureworks
go
delete from dbo.tabla_1Millon_filas
where id1 <= 10000

Y ahora ya estamos preparados para ver el comportamiento de las lecturas. Usaremos la siguiente consulta que devuelve el número de páginas en memoria para cada base de datos – con la que ya estás familiarizado:

SELECT
count(*) AS cached_pages_count
, count(*) * 8. / 1024 AS MB
,CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE db_name(database_id)
END AS Database_name
FROM sys.dm_os_buffer_descriptors
WHERE db_name(database_id) IN
('DBS_Adventureworks', 'Adventureworks')
GROUP BY db_name(database_id) ,database_id

Primero limpiaremos el cache de datos para tener unos resultados exactos (por favor, no ejecutar esto en producciónJ):

-- limpieza de caché
use master;
dbcc dropcleanbuffers;
dbcc freeproccache;

Habilitaremos STATISTICS IO que también nos muestra información válida en cuanto a las lecturas físicas y lógicas realizadas:

set statistics io on

Y a continuación, contaremos las filas que tiene la tabla de 1 millón de filas en cada base de datos con la siguiente consulta:

use DBS_Adventureworks
go
print 'Snapshot...'
select count(*) [cantidad_en_snapshot]
from dbo.tabla_1Millon_filas
go

use Adventureworks
go
print 'Source bd...'
select count(*) [cantidad_en_bd_original]
from dbo.tabla_1Millon_filas
go

Y obtenemos los siguientes resultados:

cached_pages_count MB Database_name
-----------------------------------------------------
114 0.890625 AdventureWorks

Snapshot...
cantidad_en_snapshot
--------------------
1000000

cached_pages_count MB Database_name
-----------------------------------------------------
10261 80.164062 DBS_Adventureworks
114 0.890625 AdventureWorks

Source bd...
cantidad_en_bd_original
-----------------------
990000

cached_pages_count MB Database_name
-----------------------------------------------------
10261 80.164062 DBS_Adventureworks
10324 80.656250 AdventureWorks

Que nos deja un poco sorprendidos: fíjate que de la BDS, tenemos en memoria más de 10.000 páginas, al igual que las 10.000 de la BD original. Que nos viene a tirar por tierra otro mito que existe en la comunidad, obteniendo la siguiente conclusión:

Cuando la BDS necesita leer páginas de la BD original, las páginas las sube a su caché de datos (el de la BD), independientemente de que las tenga o no "cargadas" la BD Original.

Unos cuantos datos más: si te fijas en el resultado de Statistics IO, el resultado de las physical reads nos deja un poco traspuestos J:

Snapshot...
cantidad_en_snapshot
--------------------
1000000

Table 'tabla_1Millon_filas'. Scan count 1, logical reads 10253, physical reads 0, read-ahead reads 10253, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Source bd...
cantidad_en_bd_original
-----------------------
990000

Table 'tabla_1Millon_filas'. Scan count 1, logical reads 10153, physical reads 1, read-ahead reads 10149, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

¿Tiene algún sentido que en una BD con la caché limpia (hemos ejecutado cleanbuffers), se lea el contenido de una tabla de usuario sin realizar lecturas físicas? Y además, ¿existe la posibilidad de realizar 0 lecturas físicas, y de esas lecturas físicas se lean por adelantado (read-ahead) más de 10.000 páginas? No, ¿verdad? pues STATISTICS IO nos ha engañado J

Para dejar la base de datos en el estado original utilizaremos el comando RESTORE:

use master;
restore database Adventureworks
from database_snapshot = 'DBS_Adventureworks';

Conclusiones:

Aunque conceptualmente, DBS combina los datos que mantiene la BD Original + los cambios sucedidos desde la creación de la DBS, cada base de datos es independiente, y los datos que necesita leer, residirán en su propia área de memoria:

La BD Original en el momento de creación del Snapshot tenía 100 páginas.
Con el paso del tiempo de la original se borraron 30 páginas, por lo que en la Snapshot se registraron las 30 páginas "cambiadas".

Al realizar lecturas de páginas sucederá lo siguiente:

Lecturas en la BDS de la tabla original devolverá 100 páginas, y en su área de memoria contendrá las 100 páginas.
Lecturas en la BD Original leerán las 70 páginas, y en su área de memoria contendrá las 70 páginas.