> I gave the MsiBreak method a quick try, but I couldn't make it work. I have > set MsiBreak as a system environment variable, restarted Windows Installer > service, restarted the shell window from where I invoke msiexec calls to > make sure the environment is updated. But it doesn't pop-up any prompt to > attach debugger as advertised.
That's sad to hear. I'd toss out ideas to try, but... > I haven't installed the Debugging Tools for Windows, as I run Visual Studio > elevated to debug processes. I haven't restarted my computer: restart of a > working machine with stage set to debug something is a royal PITA: the > libopenvpnmsica.dll has more than one custom property to debug, restarting > each time to switch MsiBreak to a different custom action is not viable. I've debugged using MsiBreak set in the admin CMD prompt I used to launch the MSI, so restarts aren't required. The article goes into some very nearly useful details about when this is, but... > Therefore, I'd prefer to keep own MessageBox() call in the beginning of each > custom action. It works 100%. ...not only that, but the article even suggests this: "To start debugging without MsiBreak, put a temporary message box at the beginning of the action's code. When the message box appears during the installation, attach the debugger to the process owning the message box." If you ever need to debug say, the DLL loading, then MsiBreak is the way to go. As it stands, it's *REALLY* hard to beat 100%. :) > Adding PID to the message is an option. I personally never needed it. When > running Visual Studio elevated, you press Ctrl+Alt+P, followed by "msi" > keystrokes to focus on "msiexec.exe" processes, then observe the > MessageBox()'s title (which is deliberately set to function name) in the > "Title" column of the available process list. Way faster than searching > process by PID. I've been wrong before about how easy different options are. :) > Anyway, I have extended the debug pop-up dialogs to be more informative and > include PID. Patch follows... I took a look and it looks good to me, though I agree it's not strictly necessary. Thanks, Jon _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
