Login/Register
Methods for debugging NSIS installers?
Asked Answered
debuggingnsis
P

4

16

Although NSIS allows you to build quite powerful installers, the "so low level language that it reminds me of assembly" that NSIS uses is quite prone to making mistakes and therefore, when you want your installer to do something more complex other than writing files, debugging is a must.

Until now I've used the following Dr Printf-like debugging technique:

  • In a .nsh file that I include everywhere, I define a NSIS_DEBUG_MSG macro according to the value of a DEBUG define
    • if DEBUG is on, the macro will trigger a MessageBox with the debug message
    • if DEBUG is off, the macro will do nothing

This method has served me well but it presents some disadvantages:

  • it requires me to fill the code that I feel it's the one failing with calls to NSIS_DEBUG_MSG and rebuild the installer several times until I get enough info to allow me to solve the problem
  • it will do me no good if my problem is that the installer itself fails (if the installer program dies)

So what I wanted to know is what debugging methods do you use for these installers so that hopefully I can improve mine.

Painter answered 27/10, 2009 at 13:36 Comment(1)
It would be nice to acccept an answer... – Brass
B
7

During my time using NSIS, there is these things noticeable:

I have found out that nothing is more powerful than parsing !verbose 3 level output with self-made tool ;)

I have found out that you can NOT depend on any NSIS-based debugging method. It may crash .. and your installer will crash along with it. No pretty, eh'? :(

I have found out that enabling/disabling debugging on-demand is also very powerful weapon against idsses as it allows to distinguish between unstable and failed NSIS build ( it is easier to use CI terminology though... :) ).

I have found out that verbose output w/o realtime automated NSIS testing is like driving Cadillac with bicycle engine :)

Hope it helps for those accidentally visiting this question :)

EDIT: It's always good idea to start with 3rd party tools. For example, no need to hassle around GUI as it is always easier to use tools like:

EDIT #2: I have found out that pretty effective method for debugging is to use direct documentation automatization. Currently I use the following components:

The result is that I got screenshot after nsDialog:Show plus I got updated images in wiki :) .. only stuff left is to fetch info from svnlook :)

EDIT #3: And the need of svnlook is also worked-around by building a svn log --xml exporting DLL using NSIS v2.44 header for Delphi and Lazarus IDE 0.9.30.2 :) Kudos to Lazarus!

Woohoo! :)

EDIT #4: Hit this small discussion here: http://forums.winamp.com/showthread.php?t=325521

Brass answered 10/4, 2012 at 10:54 Comment(1)
NSIS is crazy. I have to deal with a legacy nsis installer that has several thousands of lines of code. I could have written a better installer with WinRAR+Lazarus with a smaller number of lines. – Dialytic
S
5

What have saved me much time is to use the logs that are created by NSIS. Both the log while compiling the scripts, and the installation log. They allows me to check that the macros I have defined is in use, and that the installation actually run the scrips they should.

It might seem too little, but this is actually everything I need to keep my installation software of 50+ nsh files running, along with the divide an conquer principle.

Smallage answered 10/11, 2009 at 14:3 Comment(2)
Yes, only problem from gathering anf analyzing compile-time log (in my build environemnt) is that NSIS do not have any kind of compile-time bitness check. Nowdays having highly integrating logging only for 32bit is definetly not long-living solkution, not talking about basically ineffective system resource usage... – Brass
Where are the logs? – Aloft
T
3

You can download one of the special builds of NSIS from the official site that has advanced logging. This will give you very detailed logging information that makes debugging easier.

Treble answered 20/11, 2009 at 18:50 Comment(1)
If you're looking for a link – Ground
S
2

I use the DumpState plugin a lot, much better than a basic messagebox for stack issues. I alse tend to use a macro that sets all registers; $0=r0,$1=r1 etc so I know the stack is in the correct state. This is of course only useful during the design phase and not so much for debugging on the end users system...

Springs answered 21/5, 2012 at 18:1 Comment(1)
Still - it needs addition maintianing as same as nsisdbg plugin ... I dont find any advantage of doing it or having nsisdbg as output for "data structures" :/ .. PLUS, I need to fix nsis screenshot plugin to make it function normally under Windows NT 6.x OSes ... – Brass

© 2022 - 2024 — McMap. All rights reserved.