Presta atención porque en esta sección hallarás la respuesta que buscas.
Solución:
Parece que Mats y mi suposición eran correctas. MS ha rediseñado el regsvr32 de 64 bits para que, en función del valor de bits de la DLL de destino, pueda generar un nuevo proceso de regsvr32 de 32 bits de %SYSWOW64% para registrar la DLL. Para probar este punto, encendí procexp, espié la ventana emergente para la DLL de 32 bits y esto fue lo que apareció.
Un par de cosas a tener en cuenta
- La línea de comando para los mapas regsvr32 de 32 bits con el nombre DLL de 32 bits que estaba tratando de registrar
- La versión de 32 bits de regsvr32 es un proceso secundario de la versión de 64 bits de regsvr32
- El tipo de imagen y la columna de ruta
Esto debería explicar cómo sucede exactamente:
(fuente: alax.info)
regsvr32 comenzará con otro gemelo de bitness internamente para que coincida con el bitness de la DLL. Así es como el registro tiene éxito. No necesita preocuparse si inicia la versión de 32 bits o de 64 bits de regsvr32 porque se encargará del desajuste.
El escenario en el que necesita preocuparse es cuando comienza regsvr32 desde Visual Studio como host de depuración. Desea el bitness correcto allí, porque el proceso secundario con el registro real se ejecutará fuera del depurador y no podrá pasar el código.
Si posees alguna indecisión y disposición de ascender nuestro sección te evocamos dejar un paráfrasis y con mucho gusto lo ojearemos.