Note: What is described below applies to Windows Vista x64 (at least I used such OS). I’m not going to describe what to do with a mini dump – how to analyze it in a debugger (e.g. in Visual Studio); such information can be found in a very good article at CodeProject. What I’m going to present here is how to set up Windows Vista so that mini dumps are created when an application crashes, and enforce they are stored locally on the machine on which that happened.
I believe every developer uses debugger while product creation. However it’s also possible to debug the application after it’s delivered to the client. One of such techniques is postmortem debugging – the act of debugging the memory dump of a process, which is stored in a special file (not human readable).
Microsoft has created a special service – Windows Error Reporting. Prior to Vista, Dr. Watson was default Windows application debugger that created crash dumps. Starting with Vista, Microsoft has replaced Dr. Watson with a new, improved mechanism. In short (supposing Windows Error Reporting is enabled), if an application crashes a mini dump (representation of the state of the process) is created. Mini dump is much smaller but still provides plenty of needed information. Depending on settings, a mini dump can be sent to Microsoft for further analysis. This is default behavior which, at least in my case, resulted in no mini dumps stored locally on the machine where the crash took place.
Continue reading ‘Windows Error Reporting – first steps in postmortem debugging – how to collect mini dump?’
By definition a load test is supposed to simulate many users accessing a server at the same time. It consists of series of iterations, which can be either Web tests or unit tests. Each operation is repeated the defined number of times for each virtual user.
A load test completes with status ‘Completed’. If one needs to learn more details on the run, they should open the result file (trx) and read the statistics. Now, in real world something can go wrong with either the infrastructure or one of the system components. Let’s say that one of the element in a long Web test fails for a reason. In such case you would rather not wasting time analyzing the result of the test to find it out only ten, but write it off automatically.
Continue reading ‘How to abort load test when its scenario fails?’
Published on
February 10, 2010 in
IIS.
Tags: IIS.
Deployment of a new version of a site is a very tricky/risky procedure. At some point (i.e. until deployment is not completed) your service will work not as it is supposed to, which can result in reset session, HTTP errors displayed, etc. Whatever the result is it can really discourage the users of your service and, let’s be honest, will not look very professional (if not lame…).
That’s why at the time of deploying the changes, you probably should temporarily switch off the service and display the appropriate message so that the user knows the web site is being updated, and that is happening now.
Now, if you are hosting the service on IIS this is very simple to achieve. All you need to do is copy app_offline.htm to the root directory of your web site. Once the file is in place, it will be served to the user as a response to any request to your web site. Once you’re done with deployment, remove that file and the updated service will start working again.
I had a load test that used a coded web test. At some point the coded web test changed, i.e. this line was added: Outcome = Outcome.Fail;.
After this change the test stopped working – it always ended with error message: ‘User aborted test run’. Apart from that each iteration of the web test produced MethodAccessException: Microsoft.VisualStudio.TestTools.WebTesting.WebTest.set_Outcome(Microsoft.VisualStudio.TestTools.WebTesting.Outcome).
Solution
The reason for the problem was I was using Visual Studio TS 2008 without SP1. Once I installed the SP1, which must have updated mstest, the test started running successfully again.
The key point here is before SP1 Outcome was read-only property, which I learned there.
It’s a fact that coded web test methods give more flexibility to the developer, i.e. common code reuse. So let’s create a coded web test in whose GetRequestEnumerator() method you want to call a common method which tests some other requests. Let’s make it look as GetCommonRequests() in the example below:
public class AWebTest : WebTest
{
private IEnumerator<WebTestRequest> GetCommonRequests()
{
WebTestRequest req1 = new WebTestRequest("http://google.com");
yield return req1;
WebTestRequest req2 = new WebTestRequest("http://google.com");
yield return req2;
}
public override IEnumerator<WebTestRequest> GetRequestEnumerator()
{
WebTestRequest req = new WebTestRequest("http://google.com");
yield return req;
GetCommonRequests();
}
}
You would expect to see three requests in the test result. You will see only one though…
Continue reading ‘How to invoke a common coded web test method from GetRequestEnumerator()?’
It’s not really possible to fail a load test because by default it always ends with status ‘Completed’. Because of that anytime a load test completes one musts analyze the results – if performance stayed at the acceptable level. So, despite being a powerful tool, load tests require human attention, which makes the whole testing process less automate.
Continue reading ‘Is it possible to fail a load test?’
A coded web test, as opposed to a basic web test, brings more flexibility to the developer: conditioning, looping, code re-usage, etc. If you haven’t created one yet, you can follow an instruction on MSDN.
Now, because a coded web test can have some logic inside, it makes sense to add logging so that there’s a trace on what’s going on while it executes.
Continue reading ‘How to quickly add logging to a coded web test?’
I wanted to change a load test so that it works similar to what Gabriel Szlechtman described in his blog. Additionally, I followed MSDN instruction on how to create a Load Test Plug-In.
So I created a new project with a plug-in class, added a reference to it from load test project and wanted to hook the plug-in with the test. However, when I was doing the last step I was getting the following error:
Solution
The fix is quite simple. When I added a new class for the plug-in, it was defined without the access modifier (and therefore it was internal), which made the class accessible from other classes only in the same assembly. Adding public access modifier for the plug-in class solved the problem.
When I ran a load test on my environment (Visual Studio TS 2008) for the first time I got the following error:
Error occurred running test. XXX could not access the result repository: Invalid object name ‘LoadTestRun’
Solution
The reason for that was I hadn’t had created a database schema for load tests. In order to do it I executed <VS location>\Common7\IDE\loadtestresultsrepository.sql which did all the job.
Please refer to msdn for more information.
Published on
November 19, 2009 in
c++.
Tags: c++.
Initializer list in C++ looks like in the example below (see constructor od D class):
class B {
public:
B() { }
};
class D : public B {
public:
int x;
int y;
D(int _x , int _y) : x(_x) , y(_y +1) { }
};
Continue reading ‘Initializer list and initializing derived class members’
