• No results found

Troubleshooting invalid view state and failed event validation

ASP.NET uses __VIEWSTATE and __EVENTVALIDATION hidden fields to round-trip information across HTTP requests. The values for these fields are generated on the server and should be posted unchanged on a post back request. By default, these values are signed with a so-called validationKey to prevent tampering with the values on the client.

If you just record the values in a web test and post the recorded values, you can run into ASP.NET error messages about invalid view state or failed event validation. The Visual Studio web test recorder will normally automatically detect the __VIEWSTATE and __EVENTVALIDATION hidden fields as dynamic parameters. This means the dynamically extracted values will be posted back instead of the recorded values.

However, if the web server is load balanced and part of a web farm you may still run into invalid view state and failed event validation errors. This occurs when not all servers in the web farm use the same validationKey and the post back request is routed to a different server in the farm than the one on which the page was rendered.

To troubleshoot, ViewState MAC checking can be disabled by setting enableViewStateMac to false.

However, this is not suitable for use on a production environment because it disables an important security feature and has performance implications. The recommended fix is to define the same value for the validationKey on all machines.

Instructions for manually creating a validationKey are detailed at http://msdn.microsoft.com/en-us/library/ms998288.aspx. For IIS 7 a machine key can easily be created through IIS Manager, see http://technet.microsoft.com/en-us/library/cc772287(WS.10).aspx.

Visual Studio Performance Testing Quick Reference Guide Page 144 For more background information on ViewState and EventValidation go to

http://msdn.microsoft.com/en-us/magazine/cc163512.aspx.

Visual Studio Performance Testing Quick Reference Guide Page 145

Troubleshooting the VS Load Testing IP Switching Feature

1) Make sure that the Agent Service is running as a user than is an admin on the agent machine; this is required because the agent service attempts to configure the IP addresses specified in the agent properties on the chosen NIC, and admin permission is required to do this.

2) Make sure that none of the IP addresses in the range specified for a particular agent are already configured on the chosen NIC.

3) Enable verbose logging for the Agent Service:

* Edit the file QTAgentService.exe.config: (located at: <Program Files>\Microsoft Visual Studio 9.0 Team Test Load Agent\LoadTest\QTAgentService.exe.config)

* Change:

<add key="CreateTraceListener" value="no"/> to "yes"

* Change:

<add name="EqtTraceLevel" value="3" /> to “4”

* Restart the Load Test Agent service

* The file "VSTTAgent.log" will be created in the same directory as QTAgentService.exe.config.

* Re-run the load test with verbose logging configured, and look for lines in the log file that contain the text: "Attempting to configure IP address:" and "Configured IP address:" This will tell you whether or not you the agent service is attempting to configure the IP address you've specified. If you see the

"Configured IP address:" line, it has succeeded in configuring this IP address. If not, there should be some error logged.

If you have verified the items in step 1 & 2 above, and the log indicates that the configuration of the IP address is failing but you cannot determine the cause of the failure from the error message in the log (or if there is no error message in the log), post a new thread to the Web and Load testing forum, or open a Microsoft Support incident for further assistance, and provide details on the setup including the relevant portions of the log file.

4) Make sure that the load test you are running is set to use IP Switching: Click on each of the "Scenario"

nodes in the load test editor, go to the property sheet, and verify that the "IP Switching" property is set to True (normally it should be since this is the default, but it's worth checking).

5) Enable verbose logging for the Agent process.

If the log file created in step 3 shows that the IP addresses are being successfully configured, the next step is to check the agent process log file to verify that the load test is actually sending requests using those IP addresses.

Visual Studio Performance Testing Quick Reference Guide Page 146 To enable verbose logging for the agent process:

* Edit the file QTAgent.exe.config: (located at <Program Files>\Microsoft Visual Studio 9.0 Team Test Load Agent\LoadTest\QTAgent.exe.config)

* Change:

<add key="CreateTraceListener" value="no"/> to “yes”

* Change:

<add name="EqtTraceLevel" value="3" /> to “4”

* The file "VSTTAgentProcess.log" will be created in the same directory as QTAgent.exe.config.

* Re-run the load test, and look for lines in the log file that look something like: "Bound request on connection group M to IP address NNN.NNN.NNN.NNN" If verbose logging is enabled and these lines are present in the log file, IP Switching should be working.

6) If the number of unique IP addresses being used as shown by the log entries in step 5 is less than the number in the range that was configured, it could be because your load test is configured to use a connection pool with a smaller number of connections than the number of IP addresses specified. If this is the case, you can increase the size of the connection pool, or switch to "Connection per User"

mode in the load test's run settings properties.

Visual Studio Performance Testing Quick Reference Guide Page 147