LR scripts debuging on controller, try to make a "product" without a bug

These days, my team member met certain problems on the Loadrunner scripts during running in the controller, However the scripts run smoothly in Vugen with many loops...

The errors he got from LR controller is a lot with 10+ concurrent vusers
First, debugging with the first error info always:
I just want to make sure that which is the very first error, and analysis the error which page may have the problem.

Second, can we reproduce this error in the LR controller with only single user??( precondition:the scripts run smoothly in Vugen)

If Yes, then we enable the log level settings in the run-time settings: usually i want to have "always send messages"-->"extended log"-->"parameter substitution" enabled meanwhile i will add bellowing codes:
lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG|LR_MSG_CLASS_RESULT_DATA, LR_SWITCH_ON );

failed transaction;//which can be reached by the very first error info

lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG|LR_MSG_CLASS_RESULT_DATA, LR_SWITCH_OFF );

uncheck "continue on error" in run-time settings, then run the test in controller again

After running, the error show at the same place, open the log file in the result location which you set in the report menu.

Read the log like you do with vugen, then you can find which unexpected page(response data) you got, is it related to some parameters setting? or really a server problem?(you can manually verify it if it is a server error)

If No(only happens under concurrent load), the most possible problem may related to the parameters you set, I would like to have "always send messages"-->"extended log"-->"parameter substitution" enabled and uncheck "continue on error" , to check the parameters we pass into scripts in the log file after running the script.

Another way you can write some code to print out into the controller console as an error message... anyway, you need to use any manner wisely to see what exactly happened when there is an error message. Do not let every small error pass in the script tuning phase... we are making a "product" without bug :)!

Last thing, Content checking code is very very important, I found some people does not like to write this.
But it saves us from the fake performance testing, it is really harmful and misleading if our scripts do not work correctly but it does not trigger a fail transaction!