I need to VALIDATE the UFT(QTP) tool to use it in our Medical Automation testing projects. My Manual Test Lead has given a requirement that UFT must be able to recover from an Application Crash.
For this I have to use a sample application which is provided by UFT.
As of now everything is fine, as I can enable and create an Application Crash Recovery Scenario using Recovery Scenario Manager in UFT.
The problem is I have to prove them practically that UFT will recover from the application crash, for this, first I have to CRASH the sample application and then test UFT if it is able to recover from that crash.
So I have been googling about how to crash that wpf sample application provided by HP.
Please help me crashing the app.
Thanks in adv.
Is it sufficient to use Windows' taskkill command?
Related
Apologies, this may not be a good question.
I have a VB based UI application running, supported by C++ modules through COM.
a month before it started to close randomly without any clue. I initially analyzed in perspective of a application crash and expected to see Dumps and Application/System event log entries. I have prior experience in application crash debugging. tried registry configurations (Like, CorporarteWerServer for application hang, LocalDumps and all that).
But no luck.
End user says they don't see any popup like "This application is not responding with options close/wait". The application just closes down without any prompts.
We have logging enabled where we intentionally close the application using exit(). So it is not closing formally.
User does not have testing environment where we can install debugging tools and monitor.
I have verified for insufficient memory and antivirus software and they are fine.
So, Is there any cases where an application can just simply close/crash without any prompts, logs, dumps ?
Please suggest if I am missing something. Also, is there any built-in windows tools to monitor ?
Currently I have a plugin for Petrel that is used in batch mode. So Petrel is launched from the command line, with the class/method to run specified via command line parameters. All fairly straight forward.
However, I'd like this operation to be performed from a Windows service. Simple experimentation suggests this won't work due to Petrel needing to open a window and thus needing to be run from a logged in user account.
Is there a way around this, or is it impossible to run Petrel from a service?
You may be able to use PetrelEngine. It is normally used to launch Petrel in silent mode for automated testing, but I think it might work for you.
PetrelEngine.Instance.Initialize("-licensePackage Package1");
I have several random failing integration tests running on TeamCity. These tests do not fail locally. I've even tried making my local site hit the dev database.
Does anyone have experience debugging weird issues like this?
We are using MVC 4 (C#) and MSBuild.
As commented, you don't give lots of information, but the straightforward anser to the question "how to debug this" would be to put a System.Diagnostics.Debugger.Break(); statement right before the failing test. Then you'll have the chance to attach the debugger, and off you go.
The issue I was having was with a load balanced solution. The two web servers were out of sync causing odd timing issues.
One web server would save it, then another would pick it up to the processing and the time was in the past.
We are developing a new Windows Store App with C# now. It is strange that the app crashed occasionally but haven't given any infomation . Now we deploy an IDE on the Surface and use it to run our code. The app crashed as the same, and the IDE didn't give any information.
So we want to know if Win8 system will kill app at some special cases ?
By the way, our all code blocks had using try-catch and we use async and await very carefully.
Most crash happend when the App access some network service.
Thank you very much!
every body!
I think there is not any systematic mechanism to make our app crash. But some bugs on the system really influence the quality of the software.
As our app, it crashed many times when using grouped GridView and when the pages enabled NavigationCachemode. After removing these features, it crashed less.
I've attempted just about everything to get our ClickOnce VB.NET app to run under Terminal Services as a RemoteApp. I have a batch file that runs the .application file for the app.
This works fine via RDP desktop session on the terminal server. As a TS RemoteApp, however, well... not so much.
I get a quick flash of command prompt (the batch file) on the client system and then... nothing...
Same goes for having it point to the .application file directly (without using a batch file) or even copying the publication locally and having it point to that.
I found a technet.microsoft.com discussion about a similar issue, but there's no resolution to it listed.
For anyone who has run into this before and got it working, what did you have to do?
We currently use RemoteApp's for everything else on that server, so I'm hoping to stick with that if possible.
The current workaround is to build and run an MSI-based installer for the app on our terminal server whenever we publish via OneClick out to the network, but this can be quite a pain at times and is easy to forget to do.
Since the app works fine via Terminal Services when run in full desktop mode but not during RemoteApp, I don't think it's anything specific to Terminal Server permissions so much as ClickOnce requiring something that isn't available when running as a RemoteApp.
The Key to getting it to work is to use Windows Explorer "C:\windows\explorer.exe". This process is the base process when you login to a full session.
If you setup the RemoteApp to use Windows Explorer and the command line argument of the path to the .application file for the ClickOnce application then it will work when launched as a remote application. Windows Explorer will flash for a second when it starts, but it will disappear then the ClickOnce application will launch.
Why does it have to be a ClickOnce application? I would consider just deploying the exe file and assemblies.
I know it only half a solution, but if the application does not change much, it might be a good solution.
I believe your problem is related to the fact that ClickOnce needs to store it's data in a special user folder called the ClickOnce application cache. Apparently because of how Terminal Services sets up user folders ClickOnce can't access this in TerminalServices mode.
See this link for more information.
http://msdn.microsoft.com/en-us/library/267k390a(VS.80).aspx
There may not be a way to do it :(
Can you launch the .exe directly? It's buried under your profile in \AppData\Local\Apps\2.0[obfuscated folders], but you should be able to find it.
That will skip the built-in update process, but if it can be launched that way you could then write code to do a manual update after the application starts.
Faced the same problem this morning and got it resolved by copying the clickonce app's directory from the user settings folder to somewhere like c:\MyApp\ - I know its nasty and not very ideal.. but good enough for me!
We recently ran across this issue and decided to post a bug report on this issue to the Visual Studio development team. Feel free to comment on the bug report. It has to be a bug in ClickOnce caused by some changes in Server 2008.
https://connect.microsoft.com/VisualStudio/feedback/details/653362/net-clickonce-deployment-not-working-as-remoteapp-or-citrix-xenapp-on-server-2008-server-2008-r2
We also have a discussion on the MSDN forums covering this issue:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7f41667d-287a-4157-be71-d408751358d9/#92a7e5d9-22b6-44ba-9346-ef87a3b85edc
Try using RegMon and FileMon when starting the app - You may be able to track it down to a file and/or registry permission issue.
Also maybe check the event logs to see if anything's getting logged when the process fails.