Los scripts de Microsoft JScript que intentaban ejecutarse al iniciar sesión, Autoruns y su solución

shutterstock_82751101_6E4CAFF4

Conforme vamos instalando aplicaciones en nuestro sistema operativo, notaremos que algunas como Antivirus, Mensajería, Controladores, etc, se toman algunas ventajas, y se empiezan a ejecutar después de cada inicio de sesión. Esto en la mayoría de los casos empieza a ser un problema, cuando la velocidad de arranque de Windows se compromete por todos los procesos que debe iniciar previamente; pero además, cuando por una razón X o Y empiezan a generarse mensajes extraños sobre ejecuciones que el sistema operativo trata de realizar y que no encuentra. En el post de hoy, veremos un caso particular, pero un comportamiento común de este tipo de problemas.

El problema

El problema como en la mayoría de las ocasiones, surgió de una pregunta hecha en los Foros de Windows 8 de Microsoft TechNet. Cada que el usuario iniciaba sesión, estaba viendo dos mensajes relacionados con unos Scripts de Javascript que se intentaban ejecutar, pero que al parecer no estaban teniendo éxito:

E1

E2

El primero con nombre de 0216.js, estaba intentando ejecutarse desde:
C:UsersDaniaAppDataRoaming1400, y el segundo con nombre de 5e545.js, se estaba intentado ejecutar desde:
C:UsersDaniaAppDataRoamingMicrosoftWindowsStartMenuProgramsStartup.

La causa

Windows predeterminadamente suele utilizar varias ubicaciones en Explorador y Registro donde ubica las referencias de lo que se inicia por cada usuario, o por todos los usuarios. Por ejemplo, una clave distintiva para este tipo de ejecuciones, es:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun

Aunque para equipos de 64 bits, se agrega también:

HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRun

Estas dos ubicaciones se pueden utilizar a través de las políticas de grupo para personalizar ejecuciones de proceso en un ambiente local o de dominio, por supuesto, también se pueden crear las entradas manualmente desde el Editor de Registro.

Hasta Windows 7, la herramienta de MSCONFIG, embebida en Windows, tenía una pestaña de Arranque donde podíamos ver gráficamente todas las entradas que estuvieran en estas claves; característica que pasó al mejorado Administrador de Tareas en Windows 8. No obstante, MSCONFIG sigue existiendo con las demás funcionalidades.
El problema es que si el proceso se encuentra en algún directorio diferente y no muy común, no nos servirá de nada el MSCONFIG o el Administrador de Tareas, pues les quedará imposible mostrarnos otras ubicaciones por su funcionalidad tan reducida.

Así lucen las ejecuciones normalmente desde el MSCONFIG o Administrador de Tareas:

image

Esta limitación aplicaba para el caso que estoy exponiendo, así que el Administrador de Tareas no ayudaba en lo absoluto para prevenir o eliminar la ejecución de estos Scripts.

En este punto es donde por enésima vez, entran a jugar un papel fundamental las herramientas de Sysinternals. Para el problema específico, le tocó el turno a Autoruns.

Autoruns y Autorunsc (Versión de línea de comandos), tiene funcionalidades del MSCONFIG avanzadas, desde donde podemos ver absolutamente TODO lo que está iniciando con Windows, desde Controladores, hasta DLLs, Tareas Programadas, extensiones al Explorador de Windows, al Internet Explorer, etc. Además de esto, Autoruns tiene otras características únicas, que nos pueden permitir comparar varios logs de inicio, ejecución desde un Windows PE para deshabilitar controladores que puedan estar previniendo la correcta ejecución de Windows, etc.

Autoruns tiene una pestaña llamada Logon, que es a la que el MSCONFIG y actualmente el Administrador de Tareas en su pestaña de Arranque se le asemejan.

Así se vería el resultado en el mismo sistema desde el que mostré la imagen anterior:

image 
Como ven, Autoruns no solo muestra el proceso, su descripción y su estado, sino que además nos permite ver e interactuar con la ruta de ejecución, y ver  muchas más entradas que están iniciando con Windows.

Volviendo al caso, y una vez hecho el análisis con Autoruns, nos encontramos con dos entradas muy particulares en la pestaña de Logon dentro de Autoruns:

image

Justamente los dos archivos a los que se referían los mensajes, uno iniciando en la carpeta de Startup directamente, otro en HKCUSoftwareMicrosoftWindowsCurrentVersionRun.

La solución

Lo ideal sería tratar de llegar un poco más al fondo, e incluso ver qué contenían los archivos; lamentablemente, los casos que se abren en el foro no suelen tener mucho seguimiento de parte del que los abre una vez se solucionan, y es apenas normal, pues por lo general van en busca de esto.

El primer y más importante paso, es deshabilitar y en su posible, eliminar la entrada que permita la llamada a estos archivos; esto se puede hacer directamente desde Autoruns, y para este caso, lo unico que tuvo que hacer la persona que abrió el hilo en el Foro, fue quitar la selección en la izquierda de la entrada y con esto Windows no volvería a llamarlo una vez prenda, a menos que otra aplicación o proceso específico las volviera a habilitar:

image

Desde Autoruns se puede eliminar completamente la entrada haciendo clic derecho y seleccionando Delete también.

Con esto, y gracias a Autoruns, el problema de los mensajes extraños quedó solucionado.

Anexo

Si en el caso anterior, o en cualquier otro similar, quisiéramos investigar un poco más como mencioné antes, desde Autoruns podríamos hacer clic derecho sobre la entrada y hacer clic en Jump to Entry:

image

Esto nos abriría la ubicación directa del archivo, sin necesidad de ejecutarlo, y así poder trabajar sobre el Script físico, pues Autoruns solo inhabilita la entrada.
Entre otras funciones, al hacer clic derecho podríamos ir a las Propiedades generales del archivo, hacer la búsqueda por la web, o más interesante, buscar el proceso en ejecución desde Process Explorer:

image

De esta forma, no solo podríamos explorar firmas digitales, y propiedades más específica sobre el proceso, sino que además podríamos desde Process Explorer ver el arbol de ejecución y saber qué proceso padre lo genera o lo mantiene.

Como ven entonces, no solo cada herrramienta de Sysinternals es muy útil y productiva por sí sola, sino que además las principales (Process Explorer, Process Monitor y Autoruns), pueden hacer un conjunto con mucho poder para analizar y remover Malware, o bien hacer un Troubleshooting completo, si el problema así lo requiere.

Saludos,

Checho

Desplegar aplicaciones con Secuencias de Tareas en MDT 2012 Update 1

1537_Win8Logo_01_008485DD

Hasta ahora, y volviendo al tema de implementación de Windows 8, he tratado diferentes maneras de hacer el despliegue, sean manuales o utilizando herramientas automatizadas como MDT y WDS. Una de las necesidades, independiente del modelo de despliegue, es la forma como se administrará la distribución de aplicaciones, pues se pueden dejar en una imagen maestra (Arriesgándonos a que el .WIM se vuelva muy pesado) o como sería lo ideal, instalarlas durante el mismo asistente de instalación gestionado por MDT.

Por otro lado, la necesidad del despliegue de aplicaciones a través de la organización no siempre va ligada a una instalación paralela del sistema operativo, pues en muchas ocasiones es necesario actualizar las aplicaciones que ya existen, o integrar nuevos paquetes sin comprometer Windows, datos y configuraciones actuales. Es aquí donde cobra mucho sentido tener una solución como System Center Configuration Manager (SCCM), pues de otro modo, lo normal es que se tengan que hacer las instalaciones manuales pasando máquina por máquina.

Sin embargo, lo que por lo general no sabemos, es que podemos sacar un buen provecho de Microsoft Deployment Toolkit (MDT), que es totalmente gratuito, para generar nuestra propia solución para el despliegue corporativo de aplicaciones a través de la red, sin requerir mucho esfuerzo. Lo que haremos en este artículo, será partir de un Deployment Share ya creado para agregar nuevas aplicaciones e instalarlas en un equipo con Windows 8 que accederá al MDT a través de la red.

Lo que necesitamos

– Los archivos de instalación de las diferentes aplicaciones que deseamos instalar. Para este post, yo utilizaré tres que considero básicas y hasta primordiales en cierto punto:

* Adobe Reader XI (El lector de Windows 8 sinceramente no sirve).

* WinRAR

* Skype

*Nota: Están referenciados los enlaces para los instaladores offline, por si desean seguir el artículo con las mismas aplicaciones.

– Un equipo técnico, preferiblemente Windows Server (2008, 2008 R2, 2012), que tenga instalado y configurado de forma básica Microsoft Deployment Toolkit (MDT).

– Un equipo de referencia, que esté en la misma red del equipo técnico, donde se puedan instalar las aplicaciones (Preferiblemente Windows 8).

Preparando el Deployment Share

Por supuesto, debemos tener un recurso compartido básico ya montado y configurado, donde podamos agregar aplicaciones, sistemas operativos y toda clase de componentes necesarios para implementar Windows a través de la red. Para evitar repetir algo que está escrito en otros post, pueden seguir el paso a paso y crear el primer Deployment Share siguiendo este artículo:
http://geeks.ms/blogs/checho/archive/2013/02/05/implementaci-243-n-b-225-sica-de-windows-8-con-mdt-2012-update-1-y-windows-deployment-services.aspx

*Nota: Para este artículo, no es necesario crear la Secuencia de Tareas que instale Windows, ni agregar componentes como actualizaciones o controladores (A menos que se quiera instalar todo dede una sola Secuencia de Tareas).

Agregando aplicaciones al Deployment Share

Una vez hayamos creado y configurado nuestro Deployment Share, debemos empezar a importar todas las aplicaciones corporativas que deseamos tener a disposición desde MDT. Para esto, debemos realizar los siguientes pasos:

– Expandimos nuestro Deployment Share, hacemos clic derecho en el nodo de Applications y seleccionamos New Folder:

image

Se abrirá el asistente para crear una nueva carpeta, aquí especificaremos el nombre y una descripción para la misma:

image

Hacemos clic en el botón Next dos veces y en Finish para terminar el asistente. Se creará una subcarpeta debajo de Applications. El objetivo de esto, es tener un poco de orden con respecto a la cantidad de aplicaciones que se vayan agregando.

– Hacemos clic derecho sobre la carpeta que creamos, y seleccionamos New Application. Se abrirá el asistente para agregar nueva aplicación:

image

– En la página de Application Type, dejamos la selección predeterminada de Application with source files y clic en Next:

image

– En la página de Details, rellenamos todos los campos correspondientes a nuestra aplicación y hacemos clic en el botón Next:

image

– En la página de Source, hacemos clic en el botón de Browse y seleccionamos el directorio donde guardamos el instalador correspondiente, y clic en Next:

image

*Nota: Es primordial que todos los instaladores se guarden dentro de una carpeta, pues el asistente no reconoce el instalador independiente.

– En la página de Destination, editamos o dejamos el nombre que deseamos aparezca la aplicación en el asistente y clic en Next:

image

– En la página de Command Details, es donde finalmente debemos especificar la línea de comandos que haga la instalación de preferencia, totalmente automatizada. Es decir, que no haya ningún tipo de interacción por parte del usuario para asegurar que se instale incluso con personalizaciones corporativas (Si la aplicación lo permite, como Office, o el mismo Adobe). Escribimos toda la línea debajo de Command Line. Por ejemplo, para Adobe Reader XI, utilizando el nombre predeterminado del instalador, sería:

AdbeRdr11003_en_us_.exe /sALL /rs

image

Clic en el botón Next para continuar.

*Nota: Cada instalador puede tener parámetros diferentes, por lo que es conveniente haber probado la instalación con las banderas que se requieran en algún equipo de pruebas. Si requieren encontrar referencias de instalaciones desatendidas para sus aplicaciones, pueden visitar la página de ITNinja: http://www.itninja.com/

En la página de Summary hacemos clic en Next, y finalmente en la página de Confirmation, clic en Finish para terminar.

Como mencioné antes, el proceso anterior se debe repetir con cada nueva aplicación y por supuesto, una por una indicarle el comando para la instalación silenciosa que se necesite. Para este artículo, que estoy utilizando además de Adobe, WinRAR 5.0 y Skype en su última versión 6.3, tendría que utilizar los siguientes comandos:

Para WinRAR x64 5.0: WinRAR.exe /S

image

Para Skype 6.3: msiexec /i SkypeSetup.msi /qr

image

*Nota: Los nombres del ejecutable pueden variar.

Al terminar de importar todas las aplicaciones, debemos verlas en la parte derecha de la carpeta que creamos debajo del nodo Applications:

image

Creando Secuencia de Tareas

Lo siguiente, como ya tenemos todas las aplicaciones, es crear nuestra Secuencia de Tareas que se encargará de desplegar todas las aplicaciones que se seleccionen en los clientes que se carguen. Para crear nuestra Secuencia de Tareas, realizamos los siguientes pasos:

– Expandimos nuestro Deployment Share, clic derecho Task Sequences, y seleccionamos New Task Sequence:

image

– En la página de General Settings, debemos indicar un ID para la Secuencia de Tareas, un nombre y una respectiva descripción:

image

Clic en el botón Next.

– En la página de Select Template, debemos seleccionar Custom Task Sequence en la lista desplegable y clic en Next:

image

– En la página de Summary, clic en el botón Next. En la página de Confirmation, clic en el botón Finish.

Actualizando Deployment Share

Por último, hacemos clic derecho sobre nuestro Deployment Share, y seleccionamos Update Deployment Share:

image

En la ventana de Update Deployment Share Wizard, dejamos la selección predeterminada de Optimize the boot image updating process y clic en el botón Next:

image

En la página de Summary, clic en Next. En la página de Confirmation, clic en Finish.

¡Todo está listo! Nuestro último paso es conectar el equipo cliente y desplegar.

Desplegando aplicaciones

Desde el equipo de referencia (Cualquier equipo Windows), debemos conectarnos al MDT para poder ejecutar la Secuencia de Tareas.

Abrimos la ventana de Ejecutar (Windows + R) y digitamos:

Wscript.exe \<Server><DeploymentShare>$ScriptsBDD_Autorun.wsf

Donde \<Server> es el nombre del Servidor que aloja el MDT, y <DeploymentShare> el nombre de nuestro recurso compartido. Para este artículo, el nombre del Servidor es DC y el recurso compartido se llama DeploymentShare, por lo que el comando sería:

Wscript.exe \DCDeploymentShare$ScriptsBDD_Autorun.wsf

image

Nos debe aparecer la ventana de Auto-Run Windows Deployment:

image

Hacemos clic en el botón OK y debe cargar un Símbolo del sistema, seguido por el Asistente de MDT.

*Nota: Si el UAC nos pide consentimiento, hacemos clic en Aceptar para proceder.

En la página de Task Sequence, seleccionamos la Secuencia de Tareas recién creada para la instalación de aplicaciones y clic en Next:

image

En la página de Applications, expandimos la carpeta correspondiente a las aplicaciones importadas y seleccionamos las que deseemos instalar:

image

Clic en el botón Next.

En la página de Credentials, le indicamos credenciales administrativas para poder conectarnos al recurso compartido y clic en Next:

image

En la página de Ready, clic en Begin para iniciar la instalación.

Iniciará la instalación de cada una de las aplicaciones que se indicaron en el Asistente del MDT:

image

*Nota: Dependiendo de los parámetros que se hayan especificado en la línea de comandos al importar la aplicación, podremos ver o no interacción de la aplicación; lo ideal es que se especifique siempre la menor cantidad de interacción posible, para evitar que el usuario pueda interrumpir el proceso de instalación.

Al terminar, hacemos clic en el botón de Finish de la página Success para cerrar el asistente:

image

*Nota: Esta última ventana nos dirá si hubo errores o advertencias durante el proceso de instalación, al igual que se hace cuando implementamos Windows.

Nuestras aplicaciones ahora estarán disponibles desde el sistema operativo:

image

Espero sea de utilidad.

Saludos,

Checho

El mensaje de error al intentar predeterminar un programa sobre los archivos en Windows 8, Process Monitor y su solución

shutterstock_82751101_6E4CAFF4

Uno de los cambios más sutiles, pero de gran trascendencia en Windows 8, es la asociación neutral que ahora tienen los archivos; es decir, la mayoría no tiene una predeterminada como sucedía en todas las versiones anteriores. Esto ayuda a que no se den fallos en asociación errónea de los archivos (Problema muy común en Windows 7), y que el usuario la pueda asignar fácilmente cada que abra por primera vez los diferentes tipos de archivos.

La forma en que se asocian los diferentes programas a las extensiones no ha cambiado, y aunque hay incluso otras maneras de hacerlo en Windows 8 (Utilizando PowerShell, por ejemplo), las más comunes suelen ser: Ir a las propiedades del archivo haciendo clic derecho, Propiedades, y haciendo clic en el botón Cambiar, o bien haciendo clic derecho sobre el archivo, seleccionar Abrir con y darle a  “Seleccionar programa predeterminado” si los que están en la lista no nos sirven. En últimas, todas las formas resultan creando la subclave de UserChoice en el registro y el respectivo valor de ProgId para referenciar la aplicación.

El problema

En este caso, que surgió desde un hilo abierto en los Foros de Windows de Microsoft Community,  lo que sucedía es que el usuario estaba intentando realizar cambios en el Programa Predeterminado de diferentes archivos, pero al hacer clic derecho, Abrir con, y Escoger programa predeterminado, estaba obteniendo un extraño mensaje de error similar al siguiente:

image

Inglés:

“This fiel does not have a program associated with it for performing this action. Please install a program or, if one is already installed, create an association in the Default Programas control panel.”

Español:

“Este archivo no tiene ningun programa asociado para ejecutar esta acción. Por favor instale el programa o si lo tiene cree una asociación en el panel de control de Programas Predeterminados.”

No importaba con qué tipo de archivo intentara hacer el cambio, siempre obtenía el mismo mensaje de error, que sólo permitía aceptar para cerrar.

La causa

Como diferentes alternativas, que iban entre crear un nuevo usuario, hasta probar diferentes modos de abrir el archivo no funcionaban, había que recurrir a la herramienta por excelencia, es decir: Process Monitor de Sysinternals nuevamente.

Como el problema le sucedía en cualquier usuario, se podía concluir que era un evento que afectaba a toda la máquina, y no estaba asociado a una cuenta, por lo que todo lo relacionado a HKEY_CURRENT_USER (HKCU) se podía obviar, y además se manejaba desde el proceso de Explorer.exe, pues no estaba ligado tampoco a una extensión. Esto permitía hacer un filtro más preciso dentro de la traza de Process Monitor, pero para saber con ciencia cierta dónde podía estar el problema, era necesario comparar el comportamiento con un equipo funcional.

Suele ser una gran técnica, pues basta básicamente con correr Process Monitor en el equipo para reproducir el problema, y en un equipo que se pueda abrir la ventana que lanza la opción de Escoger un programa predeterminado y comparar línea por línea. Claro está, existen herramientas muy buenas para esto, como Kdiff3 pero igual requiere tiempo para analizar los resultados en ambos lados.

Después de un buen par de horas, finalmente encontré algo muy interesante dentro de la Traza que me envió el usuario con el inconveniente:

Proc1

Como ven, el proceso de Explorer.exe, utilizando la operación de RegOpenKey, que hace parte de la API de Win32 para abrir claves de Registro, intentaba abrir la clave de OpenWithSetDefaultOn, ubicada en: HKEY_CLASSES_ROOTUnknownshellOpen, pero obtenía el resultado de NAME NOT FOUND; es decir, la clave no existía.

Esta operación era la importante, porque al momento de compararla con un equipo funcional, el resultado era completamente diferente:

F2

La operación no solo era exitosa (SUCCESS), sino que además hacía consultas sobre ella (RegQueryKey), mientras que en la de arriba, la cerraba al no encontrarla. Además de todo esto, HKEY_CLASSES_ROOT se encarga de administrar todas las asociaciones que Windows requiere y utiliza, o las que no están en su equivalente de HKEY_CURRENT_USER.

Efectivamente, cuando en mi máquina funcional eliminé la clave de OpenWithSetDefaultOn, pude reproducir exactamente el mismo mensaje de error, realizando la misma operación.

La solución

Afortunadamente, la solución para este tipo de problemas con asociaciones, como en casi todos los problemas que el registro está involucrado, pasan por restablecer la clave, importándola desde un equipo funcional, y de preferencia, en limpio (Esto evita que la clave o valores ya se hayan modificado, y varíen de los predeterminados).

Para este caso en cuestión, si es que alguna vez llegan aquí porque lo están enfrentando, el procedimiento sería así:

Descargar el archivo Unknown desde aquí:

Descomprimir y ejecutar el archivo Unknown.reg que des comprime. Se deben asegurar que el mensaje de importación correcta aparezca después de la ventana de advertencia por importar claves de registro:

image

Una vez hecho esto, deberían poder acceder sin problemas a la selección de programas predeterminados desde el clic derecho como siempre:

image

Espero sea de utilidad.

Saludos,

Checho

El mensaje de Log file de VMware al iniciar Visual Studio 2012 en Windows 8, Process Monitor y su solución

shutterstock_82751101_6E4CAFF4

Como siempre he dicho en anteriores artículos relacionados, escribir sobre alguna solución de un problema en Windows, es de lo que más me gusta hacer aquí, pues afrontar algo así, es la mayor fuente de conocimiento que uno puede tener.

Uno de los tipos de problemas más frecuentes con respecto a aplicaciones en Windows, suelen ser los misteriosos mensajes de error, que en algunas veces dicen mucho, pero otras veces, puede ser una excepción no controlada, y por ende, el mensaje no dirá nada. Gran parte de estos errores se pueden subsanar, pues muchos son causados por operaciones incorrectas que hace la aplicación sobre la actual versión del sistema operativo, o bien como en este caso específico, hay problemas de permisos.

Para fortuna de nosotros, Microsoft tiene una cantidad de herramientas y soluciones gratuitas que nos ayudarán a dar una luz a nuestro problema; entre las que más destaco, están: Sysinternals Suite y Application Compatibility Toolkit, incluida en el ADK de Windows 8. Lo más interesante, es que aunque lo ideal siempre es el conocimiento, no es extricatmente necesario tener un grado muy alto para que estas herramientas nos puedan ayudar.

El problema

Regularmente al instalar Windows, vario entre VMware Workstation y Hyper-V, pero también instalo siempre Visual Studio, que hoy por hoy está en versión 2012. VMware tiene unos componentes adicionales para Visual Studio que se pueden agregar mientras se instala la plataforma.

Lo extraño de todo esto, es que después de instalar Visual Studio y VMware con sus respectivos componentes, cada que intentaba abrir la plataforma de desarrollo, estaba recibiendo este mensaje de error:

image

“An error has ocurred while trying to access the log file. Logging may not function properly.”

Cuando hacía clic en el botón OK (Aceptar), Visual Studio seguía su camino sin ningún problema, pero se empezaba a volver bastante molesto tener que aceptar el mensaje cada vez que se ejecutara la suite de desarrollo.

La causa

Claramente, el complemento de VMware para Visual Studio no podía leer o escribir el archivo de log, lo que no era posible saber, era cuál archivo específico se estaba refiriendo y en qué ruta se encontraba. Para estos casos, donde hay un mensaje de error sin mucho detalle, la mejor herramienta que podemos utilizar es Process Monitor de Sysinternals.

Como Process Monitor detecta todo evento que está sucediendo en el sistema, es normal que no sepamos en estos casos por dónde empezar con millones de resultados en la traza. Para este problema, utilicé una de las características de Process Monitor que permite filtrar por categoría y resultado. Para esto, basta con ir al menú de Tools y seleccionar Count Ocurrences:

EE1

Despues de esto, Seleccionar Result dentro del menú desplegable para asegurarnos que son los resultados los que se nos mostrarán y después darle al botón de Count.

Los resultados que yo tuve, se veían así:

image

Una de las principales causales para este tipo de errores, suelen ser los inconvenientes con permisos NTFS en el sistema operativo, así que el resultado de ACCESS DENIED es bastante útil. Lo que yo hice, fue darle doble clic para que Process Monitor inmediatamente hiciera el filtro por todos los resultados en los que haya recibido como respuesta ACCESS DENIED.

Aunque hubo varios resultados, uno en específico fue el que me llamó la atención:

A1

Como pueden ver en la captura, el nombre del proceso era devenv.exe, perteneciente a Visual Studio, lo que me decía que ocurría este evento mientras estaba en ejecución; lo otro, es que según Path, era un .log el que se estaba tratando de crear (Utilizando la operación de CreateFile), dentro de una carpeta temporal del usuario, pero más interesante aún, es que pertenecía a VMware. El nombre en cuestión era: vmware-vsid-1.log. Para estar más seguro, desde Process Monitor, hice clic derecho a la ruta y seleccioné Jumpt to, que permite navegar hasta el directorio automáticamente, y esto fue lo que vi:

image

El archivo sí estaba creado dentro del directorio, lo que indicaba que el problema quizá no estaba en su primera creación, sino más bien en la sobreescritura que hacía al iniciar Visual Studio. Para asegurarme de esto, hice clic derecho en el archivo, fui a Propiedades y finalmente a la pestaña de Seguridad para ver cómo estaban los permisos, y esto me encontré:

image

Windows me indicaba que no tenía permisos de lectura. Si mi usuario (Checho) no podía siquiera leer el contenido, no iba a poder hacer ningún tipo de escritura u operación básica sobre el archivo.

La solución

Ya sabiendo el problema, podía intentar dos cosas, darle los permisos al archivo para que el proceso de Visual Studio pudiera escribir en él, o como era un log, simplemente eliminarlo y esperar a ver qué sucedía al momento de crearse.

Opté por la segunda y lo quité, para posteriormente ejecutar Visual Studio y para mi fortuna, ¡No más mensaje molesto de error!

Al volver a resisar los permisos, todo había cambiado:

image

Uno más, gracias a Process Monitor.

Saludos,

Checho