Troubleshooting Grinder logging failure

A Grinder Node may fail to log a testcase for several reasons.

• Hooking the JavaScript side into grinder_logger.dll fail's because public symbols aren't available, so resolving the location for the JavaScript StrToDbl function cant work as expected. The is sometimes an issue for Internet Explorer after patch Tuesday as the IE public symbols may take a few weeks to be published. You would see an error in the console if this happens.

• The grinder_logger.dll failed to inject into the browser process. This is unlikely and there will be an error in the console.

• The HTML/JS fuzzer which is generating the test-cases and logging them isn't using the LOGGER class correctly. You have to call "logger.starting();" and "logger.finished();" for everything to work smoothly (See .\node\fuzzer\SimpleExample.html).

• For browsers like Chrome or IE which have a broker process and child processes, if the crash happens in the broker process, no log file can be generated because this process isn't the one which is logging the testcase.

• Grinder wont work correctly with x64 processes, yet.

• The directory where the logger tries to write the log files must have suitable permissions so the process where grinder_logger.dll is working can actually create and write files. Specified in the config file, the $logger_dir location can normally be left to its default ('C:\Users\%USERNAME%\AppData\Local\Temp\Low\').

• When a browser gets updated, the hooking stubs may need to be updated in order to correctly read out the StrToDbl parameter so that it can be passed back up to grinder_logger.dll (each browser has a class in .\node\browser\ which does the hooking). The browser will crash every time it is run and the crash will be in an allocation around the location described in the console message "Hooked JavaScript parseFloat() to grinder_logger.dll via proxy @ 0xNNNNNNNN"