Rainer Meier wrote: > There is nothing really to debug here. In case of quiet mode (/quiet > flag set at command line or quiet flag set to true in config.xml) it is > simply using the Windows logEvent method. In case that one fails it is a > Windows issue. Try commenting just the logEvent method. If it fails, > then the event log space might be full, try cleaning the logs. Where is the event log stored? > However it might also be that you just misconfigured WPKG. Which value > did you assign to the logLevel (either command line switch or > config.xml)? Please read the documentation in config.xml how the value > is constructed. It is handled as a bitmask. So probably it's just > wrongly set so you don't see all log output. Set it to "0xFF" for the > moment. The configuration is identical to the other computers that were working; I think it is 0xFF > In your output from the original post I see _ONLY_ debug severity > output. So you might have set logLevel to something like 8 or 16. The > binary representation of 8 is 1000, therefore the bits for error, > warning and information are not set - so it's not logging them. The INFO (and higher) messages weren't getting logged because this is what cause wpkg to crash. Would it be possible to wrap those lines of code in a try/catch clause? I don't think errors writing to the event handler should be fatal and cause wpkg to abort. Brian May |