LoadRunner错误及解决方法总结1. error:missing newline in d:\loadrunner\name.dat场景执行时报error:missing newline in d:\loadrunner\name.dat第二次执行不报两个解决办法：第一：如果参数不是很多的话，不要打开记事本去编辑参数，就直接在LR提供的参数的表格中进行编辑即可。
第二：如果参数很多超过100条的话。
在记事本中编辑好了之后，记着在最后一个参数后打个回车，让鼠标的光标移动到下一行。
2.load generator is currently running the maximum numb er of vuser of this type使用的是loadrunner8.0，有10000个用户的web的license，global的有10个。
在测试的时候发现running vuser到达1000以后就不能再提高，后面的vuser 就会出错。
错误是“The load generator is currently running the maximum number of vuser of this type”.已经可以排除是load generator机器本身资源的问题。
因为换了性能比较强的酷睿2还是同样的问题，CPU和memory都有空闲。
解决办法:在load generator中有一个Vuser limits tab，可以设置running user 的最大数目。
即设置load generator----Details------Vuser limits ----Other Vusers 的最大参数。
3. ERROR-26374及ERROR-26377错误no match found for the requested parameter ”Siebel_Analytic_search_id2”.check whether the requested boundaries exist in the response data. 如果初期或脚本单独回放时即出现此错误，则可能是关联问题：1.首先看下脚本中有没有使用了自动关联(web_reg_save_param)2.在Virtual的脚本里查询下web_reg_save_param的参数使用位置,然后把这个参数化给还原回来。
如果初期没这个错误，或脚本单独回放时没有问题，而是压力越大错误率越高的话，怀疑是服务器反馈不及时，或反馈信息错误，或丢包了。
导致LR没有从反馈信息中得到这个值。
Error -26609: HTTP Status-Code=503 (Service Unavailable) for":8090/logon.cfm"引起的原因解释：一、如果出现“Service Unavailable”的提示，刷新几下又可以访问。
出现这种情况是由于您的网站超过了iis限制造成的由于2003的操作系统在提示IIS过多时并非像2000系统提示“链接人数过多”，而是提示"Service Unavailable",出现这种情况是由于网站超过了系统资源限制造成的，主要是程序占用资源太多。
比如同样是100人在线的论坛，雷傲论坛所占的资源就是PW论坛所占资源的10倍以上；另外，一些死循环程序，或者不优化的程序都会占用太多的系统资源，而系统资源明显是有限的。
不过WINDOWS2003的操作系统，各网站之间是以独立进程运行的，不会相互影响。
如果一个网站的程序占资源太多或者发生太多的错误，系统日志就会提示：“应用程序池 'xxx' 被自动禁用，原因是为此应用程序池提供服务的进程中出现一系列错误，或者提示：应用程序池 'xxx' 超过了其作业限制设置。
这时，访问这个网站就会提示：Service Unavailable。
一般系统会在30秒左右恢复正常，多刷新几次就能正常访问了。
另外，如果你的网站当前访问人数过多，超过了系统的iis连接数限制，也会出现Service Unavailable的提示(win2k主机下出现连接过多就会提示：连接过多，请稍后再试；而win2003的主机刚直接提示：Service Unavailable）二、没有限制IIS连接，还是遭遇Service Unavailable多见于使用ACCESS数据库的网站一般使用windows 2003 IIS 6的用户可能这个问题一直正常的系统，突然有一个网站打不开了提示： Service Unavailable 但这个网站并没有限制IIS连接数。
然后马上影响到了别的网站，不到一会，其他的网站也全变成了 Service Unavailable这是什么原因呢？我们分析后可以知道，还是MS的老问题。
ACCESS引擎当了。
用服务器医生的文件医生修复，查看修复结果时会发现一些文件引起ACCESS引擎“灾难性故障”及“未将对象引用设置到对象的实例”的错误。
通过文件医生修复后，系统才会恢复正常。
三、浏览一个 Windows SharePoint Services Web 站点时，提示：Service Unavailable1.Microsoft Internet 信息服务 (IIS) 6.0 中没有正确地配置用于虚拟服务器的应用程序池，就可能会发生此问题。
解决方案要解决此问题，按照下列步骤操作： 1.默认的应用程序池是MSSharePointPortalAppPool。
请按照下列步骤来确定虚拟服务器正在使用的应用程序池。
a. 单击“开始”，指向“管理工具”，然后单击“Internet 信息服务 (IIS) 管理器”。
b. 展开“ServerName”，展开“Web 站点”，右键单击虚拟服务器，然后单击“属性”。
c. 单击“主目录”选项卡。
为虚拟服务器配置的应用程序池列在“应用程序池”框中。
d. 单击“确定”。
2.验证应用程序池帐户使用的密码是否正确。
IIS 不会自动轮询 Active Directory 目录服务中的密码更改。
如果应用程序池帐户是一个域帐户，其密码已过期，则在为此帐户重新指定一个新密码后，您可能会收到本文“症状”部分所描述的错误信息。
3.验证应用程序池帐户是服务器上的 IIS_WPG 组和 STS_WPG 组的成员。
4.重新启动 IIS 以回收应用程序池4.Error -27259: Pendingweb_reg_save_param/reg_find/create_html_param[_ex] request(s) detected and reset at the end of the Init section这是我犯的一个低级错误。
在我将登录脚本移到Init部分时，将登录脚本之后的浏览操作前面的web_reg_find脚本也一起移了过去，结果运行完Init部分脚本就出错了。
这种错误的现象是没有进行迭代已经出错了，错误提示也很明确。
这时只要把web_reg_find放回Action部分的正确的位置即可。
5. Error -27498: Time out while processing URL=http:// …错误分析：这种错误常常是因为并发压力过大，服务器端太繁忙，无法及时响应客户端的请求而造成的，所以这个错误是正常现象，是压力过大造成的。
如果压力很小就出现这个问题，可能是脚本某个地方有错误，要仔细查看脚本，提示的错误信息会定位某个具体问题发生的位置。
解决方法：例如上面的错误现象问题定位在某个URL上，需要再次运行一下场景，同时在其他机器上访问此URL。
如果不能访问或时间过长，可能是服务器或者此应用不能支撑如此之大的负载。
分析一下服务器，最好对其性能进行优化。
如果再次运行场景后还有超时现象，就要在各种图形中分析一下原因，例如可以查看是否服务器、DNS、网络等方面存在问题。
最后，增加一下运行时的超时设置，在“Run-Time Settings”>“Internet Protocol:Preferences”中，单击“options”，增加“HTTP-request connect timeout” 或者“HTTP-request receive”的值。
在脚本最前面插入web_set_max_retris("5"),里面的数字根据需要可以设成5，我最大设成10。
6、Error -27728: Step download timeout (120 seconds)这是一个经常会遇到的问题，解决得办法走以下步骤：1、修改run time setting中的请求超时时间，增加到600s,其中有三项的参数可以一次都修改了，HTTP-request connect timeout，HTTP-request receievetimeout，Step download timeout，分别建议修改为600、600、5000；run time setting设置完了后记住还需要在controler组件的option的run time setting中设置相应的参数；2、办法一不能解决的情况下，解决办法如下：设置runt time setting中的internet protocol-preferences中的advaced区域有一个winlnet replay instead of sockets选项，选项后再回放就成功了。
切记此法只对windows系统起作用。
问题解释：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。
这个问题很有意思！首先LR是通过Microsoft WinInet DLL去录制web协议的！但是在Control运行的时候它默认通过socket去模拟请求，因为这些可以真实的模拟带宽，而采用Microsoft WinInet DLL通过这个DLL去访问网卡方式去模拟带宽，使得模拟不是很精确！而且也不支持unix的应用，但是使用这个确实有时无法处理winnet Dll的一些请求，我认为是它的一些BUG，比如说：回放时它会检查Content-Length，但是网页支持receive more data时，这时socket模拟会一直等待直到timeout!先说了一些优缺点，最后回到这个问题！这个问题分两个方面分析：第一：你要明白web_set_timeout()这个函数的适用范围！比如说一个web_submit_data（）中实际涵盖了10个对Server 端的请求，这个函数是针对10个请求的总和时间的！（别犯低级错误，timeout分了connect,receive以及download三个部分：））第二：就是我解释的上面的一些BUG问题！WinInet dll在新版本中处理请求时可以异步的，就是不再是那种连接等待然后超时模式！但是LR用的socket是同步请求！只有等到timeout才会退出！microsoft已经明确表示INTERNET_OPTION_RECEIVE_TIMEOUT 不再适用于Microsoft Internet Explorer 5.0，显而易见，他们处理请求采取了异步处理的方式！这里，我补充如下：VuGen专用的基于套接字的重播是一种可伸缩以便进行负载测试的轻型引擎。