Tenga cuidado cuando varios usuarios usen Symstore.exe directamente contra el mismo almacén de símbolos. Los libros blancos de Microsoft sobre este tema lo hacen parecer que simplemente crea un recurso compartido y hace que todos se actualicen a través del programa SYMSTORE.EXE entregado como parte de Debugging Tools for Windows. Los libros blancos le aconsejan que haga esto en cada compilación.
Y funciona muy bien con usuarios únicos o al canalizar todas las actualizaciones a través de una sola persona que está actualizando el servidor de símbolos para un equipo.
Desafortunadamente, la "letra pequeña" en la parte inferior de algunos de los libros blancos dice que solo un usuario que ejecuta symstore.exe puede actualizar el servidor de símbolos compartido al mismo tiempo sin romper el contenido.
(Ejemplo: en http://msdn.microsoft.com/en-us/library/ms681417(VS.85).aspx, Microsoft dice: "Nota SymStore no admite transacciones simultáneas de usuarios múltiples. Se recomienda designar a un usuario como" administrador "del almacén de símbolos y ser responsable de todas las transacciones add y del. ")
Por lo tanto, no existe un mecanismo inherente para serializar las actualizaciones en el almacén de símbolos. Parece que múltiples intentos simultáneos para actualizar el almacén de símbolos pueden romper el almacén de símbolos y/o su índice.
No podemos tener versiones para todo nuestro multimillonario hombre, corporación internacional en todas las zonas horarias, dependiendo de la coordinación a través de un solo hombre en una ubicación.
Basado en esos libros blancos, planteé este problema con Microsoft en marzo de 2009; quien confirmó que este era un problema posible. Después de esa discusión, elegimos implementar un servicio de actualización de símbolos que serializa las actualizaciones a través de Direct Debug Tools Tools SDK DbgEng.DLL SymbolSrvStoreFile() Llamadas a la API por lo que nunca hay posibilidad de dos actualizaciones simultáneas contra la misma área de símbolos al mismo tiempo . Los usuarios tienen una acción de compilación que pone en cola sus símbolos a través del servicio en lugar de actualizar directamente el almacén de símbolos. Luego, el servicio serializa las actualizaciones para asegurarse de que nunca se produzcan verdaderos intentos de actualización simultáneos.
La documentación limitada disponible sobre el uso de SymSrvStoreFile no estaba muy clara en ese momento. Lo hice funcionar. Esperemos que se haya mejorado desde entonces. de lo contrario, el problema más importante fue que la ruta de entrada debe especificarse en un formato similar a _NT_SYMBOL_PATH. Por lo tanto, en lugar de, por ejemplo, usar "C: \ Data \ MyProject \ bin" como ruta de entrada, en su lugar debe especificar "srv * C: \ Data \ MyProject \ bin".
Nuestro servicio ahora también registra las actualizaciones a través de una base de datos. La base de datos funciona como copia de seguridad en el almacén de símbolos (en caso de que se corrompa y debe reconstruirse) y también crea un punto de notificación para que los gerentes y el personal de soporte sepan quién está guardando realmente sus símbolos y quién no. Generamos un informe semanal de "registro de símbolos" que se envía por correo electrónico automático a las partes interesadas.
Referencias: 1. http://msdn.microsoft.com/en-us/library/b8ttk8zy.aspx 2. http://msdn.microsoft.com/en-us/library/ms680693(v = vs.85).aspx 3. http://www.stackhash.com/blog/post/Setting-up-a-Symbol-Server.aspx 4. http://entland.homelinux.com/blog/2006/07/06/ creación-a-símbolo-servidor/ 5. http://msdn.microsoft.com/en-us/windows/hardware/gg462988 6. http://support.microsoft.com/kb/311503 7 . https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server –
¿Qué pasa si lo configuran en un recurso compartido de archivos WebDAV habilitado con IIS? Quizás eso es lo que hace MS. –
Así que tal vez lo que hay que hacer es conectar un monitor de conexión TCP y simplemente ver el tráfico que va a http://dl.microsoft.com para ver qué y cómo lo hace. –