2010-02-01 18 views
16

Estoy integrando un SDK basado en C de terceros en mi aplicación .NET. La aplicación se ejecutará como un servicio de Windows en un servidor, por lo que no debería interactuar con el usuario de ninguna manera.¿Cómo puedo evitar que una biblioteca de terceros muestre un MessageBox?

Desafortunadamente, en ciertas condiciones de error, insiste en llamar a MessageBoxA, presumiblemente para informar que algo malo ha sucedido. Cuando esto sucede, el servicio deja de responder. ¿Supongo que está esperando que alguien presione Ok?

No es posible tener el proveedor de cambiar su código para mí.

¿Hay alguna manera de que pueda hacer esta llamada en modo no operativo para que mi código pueda manejar la situación automáticamente?

EDITAR: Puede ser importante mencionar que en mi caso particular, el servicio se reiniciaría automáticamente si se bloqueara. Una salida elegante (como sea posible) y repentina es probablemente la mejor resolución para una situación en la que se muestra un MessageBox en mi caso.

+9

No es una respuesta real, lo sé, pero encuentre una mejor biblioteca/servicio. Si una biblioteca tiene este tipo de problema, es probable que tenga más. –

+0

Recuerdo que un ex compañero de trabajo idiota puso un cuadro de mensaje en un código que se sabía que era un servicio.Le dije que lo quitara pero todavía lo dejó y tuvimos que volver a lanzar el software ... no fue bueno. – Tim

+0

¡No, digamos que no es un MessageBox de una biblioteca! Buena pregunta –

Respuesta

10

Salida Detours from Microsoft Research. Le permite desviar las funciones arbitrarias API de Windows. La programación de C/C++ es necesaria para que funcione. No necesitarás mucho.

+0

Guau, no sabía que podía hacer eso. – Jeremy

+2

@nobugz Eres como una biblioteca. Seriamente. –

+0

He estado leyendo las respuestas de nobugz aquí y en los foros de MSDN, y estoy convencido de que es Dave Cutler. –

3

Se podría utilizar un editor para encontrar la ubicación de este y retire la llamada de su binario. Pero eso puede o no estar permitido bajo las limitaciones de uso del software. Ciertamente, si lo vuelve a distribuir, puede causar problemas: debe preguntar al proveedor e informarlo como un defecto y sugerirle que tenga una solución alternativa para su propio uso.

Para la gente solía hacer este tipo de cosas (licencias de craqueo u otra ingeniería inversa) esto es bastante sencillo, pero la verdadera pregunta es, ¿qué pasa si se ignora? ¿Sigue funcionando?

+1

En este caso, el bloqueo es correcto. Es mucho peor que el servicio cuelgue como lo hace. – Jeremy

+0

Bueno, entonces, si sabe que está bien detenerse, también puede simplemente salir del proceso y usar algún otro perro guardián para restaurarlo cuando no se encuentre funcionando. Evitaría esa complejidad si pudiera y solo veré si puedes salirte con NO-OPing it. Entonces, por supuesto, el problema legal con la distribución/uso? Si no conoces a nadie que tenga capacidad, conozco a alguien que solía informarme que adora usar ingeniería inversa en binarios. – Tim

+0

Ya existe un perro guardián: si el programa se bloqueara, se reiniciaría automáticamente. ¡Por eso es tan frustrante para mí que se cuelga! :) Todavía no conozco los problemas legales tampoco. – Jeremy

0

Esto no es muy fácil. Pensaría que la única forma es escribir un mensaje de enganche para atrapar mensajes transmitidos a través de todos los bucles de mensajes de Windows en el sistema. Pero ni siquiera estoy seguro de que un servicio pueda crear un enganche de mensajes dado que no tiene acceso a la estación de ventana predeterminada con sus credenciales predeterminadas (LocalSystem). Así que la tarea # uno sería ver si eso realmente funciona.

Pero aquí es un esbozo de cómo iba a tratar de hacerlo fuera de un contexto de servicio y se puede ver si se aplica:

  1. Crear una ventana hook a mensajes de captura de todas las colas de mensajes de Windows en el sistema.
  2. Trampa todos los mensajes WM_CREATE, y la sonda del parametro CREATESTRUCT de mensajes que pueden estar originando desde su biblioteca de terceros. Puede que tenga que registrar todos los mensajes WM_CREATE y luego analizar los datos para ver cómo puede diferenciar el diálogo de su biblioteca de cualquier otro diálogo en el sistema. (Muchas veces el miembro "lpszName" difiere entre las implementaciones de diálogo.)
  3. si cree que el WM_CREATE particular vino de su biblioteca, devuelva una respuesta "manejada" de su gancho de mensaje y no llame al siguiente manejador de mensajes en la cadena .

Esto es todo muy arriesgado, pero es el camino que parece que tiene alguna posibilidad para mí.

Cuestiones relacionadas