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 ?
Related
At a client of mine, in-house applications are all located on a network share. Users create shortcuts to the required applications from the network share so we can easily make sure everyone uses the latest version.
This works fairly well, although we often have an issue when users are still using applications when we'd like to release a new version. For most applications, we'd forcibly remove all the file locks on the server and release the new version. Not a very elegant solution, especially since we need assistance from another department for this.
For newer applications, I've developed a cleaner solution, where the application intermittently checks if it's still the most recent release. If it isn't, it shows a message to the user, asking him to quit the application at first convenience, or within 3 minutes. After 3 minutes, the application quits itself and all is well. However, some users will immediately try to re-start the application. The application will then show a simple MessageBox telling the user this version is currently not supported. My problem is this: while this MessageBox is visible, my executable is still locked.
I'm looking for any of the following solutions:
Releasing all locks on the current assembly files from within code
Showing a message box that lingers after the current assembly has exited
This is exactly precisely the problem that .NET ClickOnce deployment is meant to solve. Users have a shortcut they can click, the latest version is downloaded on application start, and there are no server-side executables to be locked if a user leaves their process open.
ClickOnce Deployment Overview
HowTo:Publish a ClickOnce Application
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?
I have problem printing reports to PDF through bullzip from Navision Application Server (1) if user is not in Local Admin group (2). Only under both conditions.
In Nav code I'm doing the following: init bullzip automation object (set all parameters to suppress GUI), run report to print document to virtual bullzip printer, catch output file. Thats it. Straight as a rail.
I have two environments: Windows Server 2008 and Windows 7 (different versions of Nav, but this is changing nothing). On Windows 7 it just do nothing (but works if user is admin). On server I can see error in Event Log (translated to English)
Faulting application gui.exe, version 9.8.0.1599, time stamp 0x517126dc, faulting module USER32.dll, version 6.0.6002.18541, time stamp 0x4ec3e39f, exception code 0xc0000142, fault offset 0x0006f52f, the process ID 0x3bc, application start time 0x01ce562238369fa9.
Gui.exe is a part of bullzip.
If I run the same code from Nav Classic Client, or from the same NAS launched in command line, or under local administrator account, or if i put the NAS user in local admin group - it works just fine.
To solve this problem i need to find out one of two and how to fix it:
What is the difference between local admin and regular user that could cause application to crash in non-interactive mode (service) under regular user account.
What is the difference in running NAS as service and as command line that could cause application to crash when run as service.
What I've tried so far: extend non-interactive desktop heap, give user all local privileges that admin have in gpedit. Not works. Don't know direction for further digging.
Any alternative free pdf printers advices are welcome.
This question is still actual. Though I've managed to setup PDF printing with PDFCreator. The tough part was to let several different NAS to print simultaneously. And now the setup have a bottleneck - PDFCreator's printing queue. With bullzip automations it could be avoided.
We've had some cases where third party DLL's have crashed within NAV due to permission restrictions.
The only effective way we could narrow down the files that it was trying to access was through using Process Monitor to try narrow down what was causing permission issues.
We found a folder within System32 to do with the System's Network Profile that some DLLs use. On that note, NAS's and such should be run under a domain account.
I think re-installing the application will do that,
Just make sure you are uninstalling each bullzip and ghost script,
Now Ghost script is tricky thing, if you are installing 32 bit over 64 then you are having problem,
refer this download link download appropriate version, install it,
and then install bullzip, after downloading new version from here
this will do..
then also if any problem(if you are using application for automation, you require new com object..) refer Forum, that explains most of application interface problems..
where you need to use public class PdfSettings with namespace bioPdf.
I hope this will help ..
With Visual stuido 2010, it's simple to set up SL4 to debug with an out-of-browser installed app. I followed the instructions from here and everything seems to set up fine. Debugging from the browser runs the program just fine, but running from the OOB program gives a different result. After starting, the screen will go blank and then hang forever. I have some concerns that it might be because of some of the technologies that we're using.
Firstly, there's a popup that happens because we're using WCF RIA Services (formerly .NET RIA Services).
"RIA Services will fail unless the silverlight project is hosted and launched from the same web project that contains the RIA Services."
This seems to just be a warning, but I have a suspicion that this warning might be telling me that RIA Services needs to have the .web project as its startup project.
We're also using prism and the error has an odor of a Prism error too. (something loading and then not ever appearing)
Has anyone else had any issues with OOB debugging in SL4? Is anyone else OOB debugging in SL4?
Sorry it's so vague. It's a complicated mess. The only message I see is the italicized popup warning. Then the window (which was previously showing the background of our application) just goes blank
There is currently a known issue with debugging an Out of Browser Silverlight 4 application when using F5 to launch the application from within VS 2010. The question I have is whether or not the application launches without debugging (-F5 or running it from the shortcut)? In the case of using F5, a dialog typically appears with the following error dialog “Unable to start debugging. A fatal error occured. For more details, please see the Microsoft Help and Support web site. HRESULT=0x80070018” and then the application appears to hang. In this case detaching allows the process to continue and then reattaching should allow you to debug the process.
If this is completely blocking or you’re trying to debug code running at startup (like the page startup event), one possible way to get around this would be to put in a call to System.Diagnostics.Debugger.Break, start the program and then attach when dialog pops.
This can be caused by the OOBA install being older than the version you are trying to debug. Remember, Silverlight OOBAs do not automatically update themselves to the latest version of the XAP file that may be available on the server. You have to update them yourself. If you get this error and you have included the auto-update logic in your app, just bounce out of VS, run the app so it auto-updates, then go back in and debug.
Alternately, you can uninstall the app and re-install it. That will ensure you are debugging against the latest VS build.
I ran into this same issue with VS 2008 and Silverlight 3. If I got it, I just jumped out and updated the app then re-ran it in VS and had full debugging.
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.