Vugen has detected that the application has encountered the following error

LoadRunner common questions / Issues

This blog contains the issues i have faced during my technical (performance) testing activities and their solutions / resolutions which helped me in solving the issues. The idea of this blog was to help performance testing community in sorting out the issues related to loadrunner quickly by following the steps mentioned in the blog. In order to make this blog more effective i will always welcome mails / comments from followers / viewers on their current issues they are facing.

Tuesday, April 14, 2015

VUGen Not Recording Applications Running on Chrome

17 comments:

Valuable information thanks for sharing HP ALM Online Training

IEEE Final Year Project centers make amazing deep learning final year projects ideas for final year students Final Year Projects for CSE to training and develop their deep learning experience and talents.

IEEE Final Year projects Project Centers in India are consistently sought after. Final Year Students Projects take a shot at them to improve their aptitudes, while specialists like the enjoyment in interfering with innovation.

corporate training companies in india corporate training companies in india

corporate training companies in chennai corporate training companies in chennai

I have read your blog its very attractive and impressive. I like it your blog. Digital Marketing Company in Chennai Project Centers in Chennai

Источник

Vugen has detected that the application has encountered the following error

Useful when using lots of script blocks/actions and you want to turn on full logging for specific actions or blocks. I could just have added the appropriate code in the script but instead I have 2 actions, one that turns the logging on and one off. I then add the action ahead of the action or block that I want to have full logging for and switch off after.

Here is the turn on action

lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG | LR_MSG_CLASS_RESULT_DATA | LR_MSG_CLASS_FULL_TRACE | LR_MSG_CLASS_PARAMETERS , LR_SWITCH_ON);

lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG | LR_MSG_CLASS_RESULT_DATA | LR_MSG_CLASS_FULL_TRACE | LR_MSG_CLASS_PARAMETERS , LR_SWITCH_OFF);

>
you can of course change the level of logging required.
Another trick you may need to employ with Loadrunner or indeed most of the load testing tools, is to set the timeout option.
For Loadrunner, this is in Tools > Options > Advanced settings. By default, the timeout setting is set to 2 minutes. When 2 minutes are reached, Loadrunner gives up, issues an error message and aborts execution of the automation. When logging vast amounts of data, the speed at which this data is returned to Loadrunner varies depending on network speed. Surely you say, this should not make the blindest bit of difference, the page size is the page size. Well, this is not the case. When receiving a page to a browser, compression is often used. This can shrink a 1.5MB web page to a few 100KB. With full loadrunner logging switched on, every byte is slowly and painfully returned to the automated test tool. By increasing the timeout to 4 or 5 minutes, it gives the application and the test tool time to recieve the message.

Once you have your full trace, you can sit back and enjoy a few minutes of trawling through the data as you attempt to correlate a 2 byte field.

When executing performance or load tests, test tool logging should be set very low, if not switched off. Logging does not slow users down, but it can cause injectors to use much more CPU, and of course, if the load generator is running slow, then this can cause the users to slow down. It can be an option to have just one user per automated function with logging switched on if necessary.

Источник

Load Runner Error-Solution

Saturday, 2 June 2012

Debugging steps for issues about Virtual User Generator (VuGen)

Try to login to the machine as a local administrator

Try to log in as a local administrator rather than user who is currently logged in. If this helps resolve the issue of VuGen crashing this would indicate that the cause of the problem is privileges of this particular user who is logged in. Check with your System Administrator on what privileges can/cannot be added to this user.

Make sure that there are sufficient Disk Space

Make sure that you have enough disk space available on the VuGen. If the machine does not have enough disk space, it can cause problem.

Try to recreate the VuGen’s initialization file

Sometimes, the initialization files can become corrupted (e.g. after a crashed). You will have problem in launching or using the VuGen after that. Use the following steps to do delete the initialization file so that a new copy will be created:
1. Shut the VuGen.
2. Navigate to the C:Winnt ( or C:Windows for Windows XP machine )
3. Delete the file named vugen.ini.

Check the temporary environment variables

Unlike the earlier window’s versions, Window 2000 and Window XP have the default environment set to c:Document and Settings Local SettingsTemp instead of c:Windowstemp. This long path with a space can cause several problems on LoadRunner. To resolve the issue, change to a directory without empty spaces.

Verify the MDAC version

1. Browse to C:Program FilesCommon FilesSystemMSADC
2. Riight click on the MSADCO.DLL Choose Properties
3. Click the Version tabThe File Name Version will indicate what version you are using.

NOTE: You can right click on any of the .DLL files in the MSADC directory and they should all display the same version information.

Reboot

Shut down all unnecessary processes

Disable anti-virus software

Reinstall

In case that all the above steps fail, the only recourse left would be to try to uninstall LoadRunner. It is possible that either a previous version of LoadRunner was on the machine before the current installation or that the installation did not go properly although the installation did not give any errors. It is recommended that a full uninstall be done in this case. The following steps are for a full uninstall:
1. Make sure that, all running LoadRunner processes (including the Controller, VuGen, Analysis and the Remote Command Launcher (for 6.x) or the LoadRunner Agent Process/Service (for 7.x) are closed.
2. Backup any existing scripts that may have been saved in the LoadRunner installation folder (The scripts are sometimes saved in a ‘scripts’ subdirectory under the LoadRunner installation folder.).
3. Run the uninstall program from the LoadRunner program group (or) use the Windows add/remove programs from the Control Panel. If any prompt is given about removing shared files, remove all the shared dlls that are reported as no longer being in use. In the very rare instance this causes a problem for some other application it may be necessary to re-install that other app. This is not generally a problem because every application should have registered which DLLs it needs to run.
4. Reboot the machine after the Uninstall wizard is complete. This will complete the basic uninstall procedure.
5. Delete all LoadRunner Folders. (Including the ones in the startup menu for Remote Command Launcher (LoadRunner 6.x) or Agent Process (LoadRunner 7.x)

7. Do a search for the following files and remove them from all locations — they will be replaced during the re-install.
a. wlrun.*
b. vugen.*

8. Bring up the registry editor: (Start à Run à regedit).

9. Delete the following keys:
a. Only for LoadRunner 6.x
HKEY_LOCAL_MACHINESOFTWAREBORLAND
b. If Load Runner is the only Mercury Interactive product on this machine, then delete
HKEY_LOCAL_MACHINESOFTWAREMercury Interactive.
HKEY_CURRENT_USERSOFTWAREMercury Interactive.
c. Else delete
HKEY_LOCAL_MACHINESOFTWAREMercury InteractiveLoadRunner.
HKEY_CURRENT_USERSOFTWAREMercury InteractiveLoadRunner.

10. Empty the Recycle-bin.
After you remove these items, you can re-install LoadRunner. Also, make sure that you do not have any anti-virus programs running while you are installing LoadRunner. That has been known to cause some problems with the installation of LoadRunner.
NOTE: Reinstallation should only be done for the following certain circumstances.
1. The crash only happens on a particular machine.
2. Some feature that was previously working is now crashing.
3. The above options were tried before hand.

Источник

VuGen Script Recording, Replay and Dynamic Values with Correlation

LoadRunner VuGen Script Recording, Replay and Handling Dynamic Values with Correlation Technique:

In this Intensive LoadRunner Training Series, we learned more about LoadRunner Recording Options in detail.

In this tutorial, we will discuss the following:

1. Script replay
2. Handling of dynamic values using ‘Correlation’ (and Recording Options part 2)

In the previous tutorial, we saw how to create the script. So now, let’s replay the script that we created in the last tutorial.

What You Will Learn:

VuGen Script Replay

Click the replay button (highlighted in red) or use the shortcut ‘F5’ to replay the script.

During the replay, VuGen runs each and every step in a sequence, the current step being run is highlighted with a yellow arrow on the left (as shown in the below figure).

Also, the following two tools are important (to observe) during (and after) the replay:

(i) Run-time viewer – This gives an approximate response page as seen on the browser for every request. Remember that this is not an actual browser, hence it may not display the correct response page every time. But this tool gives an idea of how the response looks like.

(ii) Replay log – The log of script replay.

In general, logs are very useful for debugging VuGen scripts. To view logs, we can open the Output window (View->Output) and select the type of log (Replay log in this case).

Also, the level of logging can be set in the Run-Time Settings (we will discuss Run Time settings in detail in our subsequent tutorials). While debugging the scripts, it is recommended to enable ‘Extended Logging’ always (to be able to see the complete log – request/response, parameters etc.).

Once the script replay is completed, VuGen will show the replay status as ‘Passed’ or ‘Failed’ (as shown below).

The VuGen ‘Passed’ status may not necessarily mean that all the requests have passed (or performed what it is intended to do exactly) during the replay. It only means that VuGen has not encountered any error while replaying the script. VuGen by itself cannot verify if the response to each and every request is correct or not (we will see how to handle this in our subsequent tutorial on how to handle this).

If we see carefully, the runtime viewer showed the following message (highlighted in red) when the second request (login request) was replayed.

The same can be seen in the Replay log.

Which means the response of the second request is not correct (expectation was to get the home page for the user but instead we got this error page).

Why did this happen?

This could have happened because of a ‘bad’ value (data) in the request (login request in this example). We will come back to the causes of this error in this specific login request a little later in the tutorial, but first, let’s understand the types of values (data) that we see in general in a VuGen script.

A VuGen script can have two types of data/values that we may need to handle –

1. Static values: The values that a user enters. E.g. Username, password, credit card details etc.
2. Dynamic values: The values that are generated and sent by the server. Examples are session ids/tokens, session states, date values etc.

We will talk about the second type (dynamic values) in this tutorial.

Say, a client sends a request (first request) to the server and receives the response which has a unique dynamic value (generated and sent by the server). E.g. Session Token ‘Zmnnijo’ in the diagram shown. And this value, being dynamic, changes every time when the first request is sent.

In the next request (second request), the client may be required to send this dynamic value to the server.

In the VuGen script, we may see such dynamic values in the request. The script when replayed with the same value may fail because the server may not be able to recognize it. So, we have to capture such types of values (from the response it is present in) into a parameter and substitute this parameter into the request(s) where it is present/required.

This is called ‘Correlation’ and is one of the most important tasks to do while working with the VuGen scripts. So, how do we do ‘Correlation’? We do it using one of the correlation functions as shown below. These functions capture the dynamic value from the response of a particular request and save it into a parameter.

1. web_reg_save_param
2. web_reg_save_param_ex
3. web_reg_save_param_regexp
4. web_reg_save_param_xpath

Now coming back to our Web Tours VuGen script and the error we were getting during the replay for the second request (login request), if we see carefully, we have a userSession value in the request.

This value was not entered by us (the user) during recording. Such values are the unique dynamic values that we were talking about.

So in this case, while recording, this value was generated and returned by the server (in one of the responses) and is in turn sent by the client (browser) in this particular request (login request).

Now, because we left this value as hard-coded, during replay, when this request was sent to the server, the server was not able to identify this value and hence, it returned an incorrect response.

So we have to correlate this value to fix the error.

Correlation

Correlations can be done in two ways:

• Manual Correlation
• Automatic Correlations
  • Record
  • Replay
  • Rules

#1) Manual Correlation:

In manual correlation, we manually insert the correlation function in the script to capture the dynamic value. Let us do this for the ‘userSession’ dynamic value for our login request. We will use the first correlation function, ‘web_reg_save_param’ to do this.

On a high-level, these are the steps to be followed for doing the manual correlation:

a) Identify the dynamic value(s) in the script: This can be done by recording the user actions on the application (creating VuGen script) twice with the same input data (static values like user id, account number etc.). Now compare the two scripts using text comparison tools like WDiff, BeyondCompare etc. We can use the in-build comparison option in VuGen which in turn will open the WDiff tool.

b) Identify the left and right boundaries of the dynamic value: Search for this value in the ‘Code Generation’ log (Generation Log) and find the Left Boundary and the Right boundary of the dynamic value.

c) Identify the request whose response contains this dynamic value: In the ‘Code Generation’ log, after we search for the dynamic value in a particular response, go up (in the log) till we see the corresponding request (that is just above this response).

d) Insert the correlation function: Insert the correlation function in the script just above the request we identified in the previous step.

So for our Web Tours script, search for the userSession value in the Generation Log (Code Generation 123211.212069664zDDHzHzpHcAiDDDDDiAczpAzADcf

And identify the left and right boundaries.

So the left boundary can be this – name=”userSession” value=”

And right boundary can be this – “/>

Our correlation function can be like this.

web_reg_save_param (“corUserSession”,”LB=”,”RB=”, LAST);

The ‘web_reg_save_param’ function has each attribute in double quotes and the attributes are separated by a comma. We have used three attributes here – the first one ‘corUserSession’ is the name of the parameter into which we want to capture our dynamic value (we can give any name here), the second one ‘LB’ is the left boundary and the third one ‘RB’ is the right boundary.

‘LAST’ signals the end of attributes (we have more attributes, which will be discussed a little later in this tutorial).

Finally, our correlation function will look like this (note that we have to put an escape character ‘’ before any double quotes in the left and right boundaries).

web_reg_save_param (“corUserSession”,”LB= name=”userSession” value=””,”RB=”/>”, LAST);

Let’s insert this function in our script now.

As the value to be correlated is in the second request (login request), and there is only one request above this, obviously, this value would have come in the response of the first request. So we will put the function just above the first request and replace the dynamic value in the second request with the parameter name (note that parameters are always put in curly braces).

And when we replay the script now, we get the correct page/response for the login request.

The replay log clearly shows the capturing and saving of the dynamic value into the parameter

And substituting the same in the second request.

So we have successfully done with manual correlation.

Let’s see all the attributes of ‘web_reg_save_param’ function in detail:

#1) LB: The left boundary of the dynamic value that we are trying to capture. If LB is not specified, VuGen uses all of the characters from the beginning of the response as the boundary.

#2) RB: The right boundary of the dynamic value that we are trying to capture. If RB is not specified, VuGen uses all of the characters till the end of the response as the boundary.

#3) ORD: This is an optional attribute that is used to capture a particular instance of a match. If we set “ORD=2”, the second instance of the match will be captured and so on (default is “ORD=1”). If we specify “ORD=ALL”, then all the match occurrences will be saved as an array.

#4) SaveLen: This is an optional attribute that is used to specify the length of a sub–string of the found value to save to the parameter. The default is –1 (meaning – save to the end of the string).

#5) SaveOffset: This is an optional attribute that is used to specify the offset of a sub–string of the found value, to save to the parameter. The default is 0 (meaning – save the entire string found without trimming any character).

#6) Search: This is an optional attribute that is used to specify the scope of the search.

It can take the following values:

• Search=Headers (Search only the headers)
• Search=Body (search only the body)
• Search=Noresource (search only the HTML body, excluding all headers and resources)
• Search=ALL (this is the default)

#7) Convert: This is an optional attribute which can take one of the following values:

HTML_TO_URL: To convert HTML–encoded data to a URL–encoded data format.
HTML_TO_TEXT: To convert HTML–encoded data to plain text format.

#8) IgnoreRedirections: This is an optional attribute and can take one of the two values – “Yes” or “No”.

If “IgnoreRedirections=Yes” is specified and the server response is redirection information, then this response is not searched for the dynamic value but a GET request is sent to the redirected location and the search is performed (for the dynamic value) on this response.

The default one is “IgnoreRedirections=No“.

#9) NOTFOUND: This is an optional option for handing when a boundary is not found.

It can take two values:

Notfound=error (the default value, causes an error to be raised when a boundary is not found)
Notfound=warning (does not issue an error if the boundary is not found)

#10) RelFrameID: This is an optional attribute that is specified to mention the hierarchy level of the HTML page relative to the requested URL. The possible values are ALL or a number.

#2) Automatic Correlation:

VuGen can also handle the dynamic values automatically after scanning the code (request, response etc.) internally. This is called ‘Automatic Correlation’.

Automatic correlation can be of three types.

1. Record – VuGen scans the code during recording and provides correlation suggestions.
2. Replay – VuGen scans the code during replay and provides correlation suggestions.
3. Rules – VuGen scans the code as per the rules we define in ‘Recording Options’.

Let us discuss the recording options related to automatic correlations (Recording Options part 2) which we did not discuss yet.

General-Code Generation: Here we can enable/disable the automatic Correlation scan. If we disable this, VuGen will not scan for automatic correlations.

Correlations-Configuration: Here we can specify the configuration for automatic correlation – like enabling/disabling scan types (Record, Replay, Rules), function to be used for correlation etc.

Correlations-Rules: Here we define rules for ‘Rules Correlation’. Rules for some types of applications will already be here by default. We can add our application (using ‘New Application’ button) and rules (using ‘NewRule’ button) if we wish to. We can also export/import rules.

So if we enable the Correlation scan option, when we record the script after the script is generated, VuGen performs some postscript generation activities and scanning for correlations is one among these.

After the scan is complete, VuGen opens ‘Design Studio’ window with the list of recommended values for correlation (Type can be Record, Replay or Rule). We can select any of these values and click on the ‘Correlate’ button to complete the automatic correlation.

Also, we can open the Design Studio window and scan for correlations at any time in the VuGen script (Design->Design Studio)

Update:

We have a hands-on video tutorial recorded on earlier LoadRunner version. The steps are still applicable in Micro Focus LoadRunner.

VIDEO Tutorial: VUGen Script Recording

Tutorial Summary:

This tutorial provides details of Vugen script recording.

• Protocol is the pre-requisite of script creation.
• Protocol Advisor is used to find the protocol that the application is using.
• ProtocolAdvisor is beneficial to performance testers by making the process of script creation faster and more focused. The tutorial covers how to use Protocol Advisor to find the protocol and jump to the scripting from there.
• We also discussed transaction and its significance, functions used to create a transaction and how to capture response time of a request through them.
• Transactions are created to capture request of each action going to the server during script recording.
• A verification point in the form of textcheck is inserted before closing the transaction to confirm that the server is responding with the correct response. In case response is not as expected, the text check will fail, and that will fail the transaction also.
• The sample application that comes along with Vugen is used for demoing – Protocol Advisor and script recording through Vugen.
• For scripting modularapproach is taken as it gives more control over the script.
• During recording elements of the floating recording toolbar is discussed and used while recording.

After going through this tutorial, viewers will be able to have an exact idea what is required to start recording a script and how that can be achieved.

This brings us to the conclusion of this tutorial.

Conclusion

Just to summarize, in this tutorial, we discussed ‘Script replay’ and ‘Correlation’.

We will discuss more on Parameterization in our upcoming tutorial!!

Источник

---

Vugen.exe

Common Vugen.exe Issues

Partial List of vugen.exe HP LoadRunner Version 9.0 Errors:

• «Vugen.exe Program Error.»
• «Invalid Win32 Program: vugen.exe»
• «Vugen.exe has encountered a problem and needs to close. We are sorry for the inconvenience.»
• «Can’t locate vugen.exe»
• «Vugen.exe can’t be found.»
• «Error starting program: vugen.exe.»
• «Vugen.exe not working.»
• «Vugen.exe failure.»
• «Faulting Application Path: vugen.exe.»

Usually vugen.exe errors with HP LoadRunner Version 9.0 happen during startup or shutdown, while vugen.exe related programs are running, or rarely during the OS update sequence. It’s important to note when vugen.exe issues happen, as it helps troubleshoot HP LoadRunner Version 9.0 problems (and report to Mercury Interactive (Israel) Ltd.).

Causes of Vugen.exe Errors

These vugen.exe troubles are created by missing or corrupt vugen.exe files, invalid HP LoadRunner Version 9.0 registry entries, or malicious software.

Especially, vugen.exe errors stem from:

• Corrupted or invalid vugen.exe registry entry.
• Virus or malware infection that has corrupted the vugen.exe file or related HP LoadRunner Version 9.0 program files.
• Vugen.exe maliciously deleted (or mistakenly) by different rogue or valid program.
• Another program is in conflict with HP LoadRunner Version 9.0 and its shared referenced files.
• Corrupt download or incomplete installation of HP LoadRunner Version 9.0 software.

If VuGen crashes intermediately or shows abnormal behavior, verify/try the following:

Try to login to the machine as a local administrator

Try to log in as a local administrator rather than user who is currently logged in. If this helps resolve the issue of VuGen crashing this would indicate that the cause of the problem is privileges of this particular user who is logged in. Check with your System Administrator on what privileges can/cannot be added to this user.

Make sure that there are sufficient Disk Space

Make sure that you have enough disk space available on the VuGen. If the machine does not have enough disk space, it can cause problem.

Try to recreate the VuGen’s initialization file

Sometimes, the initialization files can become corrupted (e.g. after a crashed). You will have problem in launching or using the VuGen after that. Use the following steps to do delete the initialization file so that a new copy will be created:
1. Shut the VuGen.
2. Navigate to the C:Winnt ( or C:Windows for Windows XP machine )
3. Delete the file named vugen.ini.

Check the temporary environment variables

Unlike the earlier window’s versions, Window 2000 and Window XP have the default environment set to c:Document and Settings<user-name>Local SettingsTemp instead of c:Windowstemp. This long path with a space can cause several problems on LoadRunner. To resolve the issue, change to a directory without empty spaces.

Verify the MDAC version

Make sure that you have MDAC 2.6 or higher installed.

Check the version of the MSADCO.DLL file:

Reboot

When programs crash, they leave the system in an unstable state. This can cause many other problems that seem to have no apparent reason for happening or has not happened before. When the system is rebooted, it resets the system into a more stable state. This should be done after any program crashes.

Shut down all unnecessary processes

Some programs are designed to have certain DLLs «hook» or be loaded into another program’s memory space. Normally, this should not have any effect on the application itself. However, it can interfere with some programs and cause them to behave erratically or crash.
For such, it would be recommended to shut down all processes that are not necessary, regardless if they hook into LoadRunner or not. Any programs that run as an icon in the system tray or on the taskbar are the first candidates for termination. Also, you can look through the list of processes in the Task Manager (right-click on the taskbar and select «Task Manager»). Some processes are system processes, which may not be able to be shut off, but any processes that can be shut down should be.

Disable anti-virus software

It is known that anti-virus software is intrusive when they are set to look for viruses. However, in searching for viruses, the software can interfere with a program’s proper execution. This could cause problems and sometimes crashes. This is why, for debugging purposes, we would recommend turning off the anti-virus software.
The icon for the anti-virus software resides in the system tray (where the clock is located). Normally, you should be able to right-click on the icon and select «disable.» However, some setups do not allow a user to turn off the anti-virus software. It is recommended to speak to a system administrator to get the anti-virus program disabled for a short period for debugging the problem.

Reinstall

In case that all the above steps fail, the only recourse left would be to try to uninstall LoadRunner. It is possible that either a previous version of LoadRunner was on the machine before the current installation or that the installation did not go properly although the installation did not give any errors. It is recommended that a full uninstall be done in this case. The following steps are for a full uninstall:
1. Make sure that, all running LoadRunner processes (including the Controller, VuGen, Analysis and the Remote Command Launcher (for 6.x) or the LoadRunner Agent Process/Service (for 7.x) are closed.
2. Backup any existing scripts that may have been saved in the LoadRunner installation folder (The scripts are sometimes saved in a ‘scripts’ subdirectory under the LoadRunner installation folder.).
3. Run the uninstall program from the LoadRunner program group (or) use the Windows add/remove programs from the Control Panel. If any prompt is given about removing shared files, remove all the shared dlls that are reported as no longer being in use. In the very rare instance this causes a problem for some other application it may be necessary to re-install that other app. This is not generally a problem because every application should have registered which DLLs it needs to run.
4. Reboot the machine after the Uninstall wizard is complete. This will complete the basic uninstall procedure.
5. Delete all LoadRunner Folders. (Including the ones in the startup menu for Remote Command Launcher (LoadRunner 6.x) or Agent Process (LoadRunner 7.x)

7. Do a search for the following files and remove them from all locations — they will be replaced during the re-install.
a. wlrun.*
b. vugen.*

8. Bring up the registry editor: (Start à Run à regedit).

9. Delete the following keys:
a. Only for LoadRunner 6.x
HKEY_LOCAL_MACHINESOFTWAREBORLAND
b. If Load Runner is the only Mercury Interactive product on this machine, then delete
HKEY_LOCAL_MACHINESOFTWAREMercury Interactive.
HKEY_CURRENT_USERSOFTWAREMercury Interactive.
c. Else delete
HKEY_LOCAL_MACHINESOFTWAREMercury InteractiveLoadRunner.
HKEY_CURRENT_USERSOFTWAREMercury InteractiveLoadRunner.

10. Empty the Recycle-bin.
After you remove these items, you can re-install LoadRunner. Also, make sure that you do not have any anti-virus programs running while you are installing LoadRunner. That has been known to cause some problems with the installation of LoadRunner.
NOTE: Reinstallation should only be done for the following certain circumstances.
1. The crash only happens on a particular machine.
2. Some feature that was previously working is now crashing.
3. The above options were tried before hand.

---

---

---

---

---

---

---

---

---