Hi,
I have installed VUGEN software on Windows VISTA Enterprise Operating system with service pack1, Internet Explorer 7.0.6001
While recording the scripts I am facing problem with Internet Explorer and showing an error message that Internet Explorer has stopped working.
After goggling and doing some work around i am able to record the script but the concern is i have to restart the system every time when i record the script.( this is not a Permanent solution/Good practice)
I followed below mention steps
Windows has an a feature called Data Execution Prevention(DEP) which is capable of causing such problems while recording.
Disable DEP for LoadRunner and Application Under Test(AUT) by navigating to Control
Panel>System>Advanced>Performance Settings>Data
Execution Prevention.
Now select the second radio button and add LoadRunner(VuGen.exe) and Application
Under Test and press 'Apply'
Note: if your application is web based then remove DEP for IE as well.
Can anyone help me in getting the solution, where I need to restart my machine every time
when I record the script.
Thanks & Regards
Mayank
Amazing how two people can have the exact same problem and question….
1. Please check your system requirements related to your version of LoadRunner, your operating system selection and your browser manufacturer/version
2. Is your version of Vista Enterprise 64 Bit? If so, you should note that VUGEN and related components are 32 Bit programs. What is your expectation with regard to a 32 bit version of VUGEN working correctly/recording a 64 bit browser? How does your expectation match with the documentation for your version of LoadRunner (as well as LoadRunner 11)
James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix
--
You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en
Application Name: iexplore.exe
Application Version: 7.0.6001.18498
Application Timestamp: 4c28b29a
Fault Module Name: bbhook.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 496e148e
Exception Code: c0000005
Exception Offset: 0000259c
OS Version: 6.0.6001.2.1.0.256.4
Locale ID: 1033
Additional Information 1: 40d4
Additional Information 2: 4062ad41ec8067256aa4c5e2b56d3c79
Additional Information 3: 40d4
Additional Information 4: 4062ad41ec8067256aa4c5e2b56d3c79
Read our privacy statement:
http://go.microsoft.com/fwlink/?linkid=50163&clci
Please take a look at your installation requirements document. Right now I am looking at a copy of a 9.5 installation doc pulled from the Internet. Granted, the document is a Japanese translation on the HP website, but under OS Support it mentions the following:
Vista SP1
XP Pro Sp2/3
Windows Server 2003 Standard/Enterprise SP2
Windows Server 2003 Standard/Enterprise R2 SP2
If you are running outside of the requirements context as noted for your release of LoadRunner with the installation manual then you put yourself in a kind of nebulous area on support when/if you have issues, for if you call the vendor and they are unable to resolve your problem they can (and will) fall back to a limitation of support for installation in an environment not noted in the requirements document. This is a difficult position to be in with a test tool, for it kicks open the door to legitimate criticism from your end users who may want to attack the veracity of your results by attacking your tool and test environment setup. And it makes support much more difficult.
It should be noted that all vendors engage in this “limitation of support” behavior, not just HP. Have you ever tried calling Microsoft for a piece of hardware which wasn’t working with your windows installation and it wasn’t on the hardware compatibility list? Then you have run into the same limitation of support issue.
My fallback would be to point you to your installation guide, to reaffirm what is specifically listed for version and service pack, then install the software on that platform and see if you still have the same issue. This affirmation of requirements also extends to the rights and credentials of the user who is using the software, to confirm that your test user matches what has been noted in the system requirements.
As a test tool you want your environment to really be as boring as possible. No issues related to the tool. When the test runs you want issues associated with your app to percolate to the top. When you start thinking, “hey, wouldn’t it be cool to…” associated with your test bed then you had better be certain that your cool config is explicitly supported by the requirements documents or greater than 90% of the time you are going to have issues that cloud your results and yeah, it’s likely related to your coolness factor elements. That is “bad magic” from a testing perspective.
<Error.jpg>