My project kept crashing after being swiped-down minimized with a code 1.
Debug Output:
'WWAHost.exe' (Script): Loaded 'Script Code (MSAppHost/1.0)'. The
program '[7048] WWAHost.exe' has exited with code 1 (0x1).
I couldn't find any problematic function so as a test I created a brand new project and just built and ran it. It crashed with the same code perhaps 30 - 45 seconds after being swiped down.
I searched here, Google, and the MSDN and couldn't find any info.
Any pointers?
Thanks.
Swiping down is actually closing the app, not minimizing it, and Visual Studio is just telling you that the app's process was terminated (due to user/system command) with the exit status.
That message is expected behavior and no cause for concern, unless you also see a runtime error before that exit message.
BTW, you can debug suspend & terminate events from Visual Studio while the app is running via the Debug Locations toolbar or the Debug menu. In some cases, you might write code to react to being suspended/terminated (e.g. to save state/data). There's more on Windows Store app lifecycles if you're interested.
try go to your project folder / bin / and remove the debug folder and then run your project again.
Related
I am working with a 64-bit Windows installer on a 64-bit Windows 10 system that has intermittent crashing issues, where it will crash and close without displaying any kind of error message. This occurs when clicking through the installer's UI, it does not actually attempt to install anything. Collecting a crash dump, I saw that it listed the exception as an "unknown error) 0xC000409. When I ran the crash dump through Visual Studio's debugger in order to obtain information, the message said:
Unhandled exception at 0x00007FFCA685C56F (ntdll.dll) in msiexec__PID__9356__Date__11_01_2021__Time_01_46_34PM__594__Second_Chance_Exception_C0000409.dmp: RangeChecks instrumentation code detected an out of range array access.
The stack trace collected from the crash dump says the following:
ntdll!LdrpICallHandler+f
ntdll!RtlpExecuteHandlerForException+f
ntdll!RtlDispatchException+244
ntdll!KiUserExceptionDispatch+2e
ntdll!LdrpDispatchUserCallTarget+e
msi!CMsiRecord::Release+12e
msihnd!CMsiHandler::CreateControls+18e
msihnd!CMsiHandler::CreateNewDialog+6ba
msihnd!CMsiHandler::RunWizard+564
msihnd!CMsiHandler::DoAction+6e6
msi!MsiUIMessageContext::ProcessMessage+1816
msi!MsiUIMessageContext::RunInstall+1ed
msi!RunEngine+1c9
msi!MsiInstallProductW+11f
msiexec!DoInstallPackage+20e
msiexec!ServerMain+1009
msiexec!WinMain+36
msiexec!__mainCRTStartup+1a0
kernel32!BaseThreadInitThunk+14
ntdll!RtlUserThreadStart+21
As far as I am aware, there were no major changes made to the installer recently. It just suddenly started getting reported that the installer was crashing, and this was the information that I was able to compile so far. My question is if there's any way to troubleshoot the installer during runtime so that I can get to the bottom of this, or are there any potential fixes I can explore applying? I've done lots of googling on this error and I haven't been able to find a related result yet.
I have also attempted to use ProcMon to see if a file is being blocked but have yet to find anything. I attempted to attach debuggers to the installer to produce a runtime failure, but because it appears to be going into Microsoft code, I can't get a look at the source or the information that it's working with.
I attempted to gather Windows Installer logs, but the log just cuts off at the moment of crashing without displaying any useful exception information. As best as I can gather, the crash occurs when the installer tries to create a dialog.
UPDATE: Some questions:
1) Do you have any custom actions in the setup GUI?
2) Is this a GUI-set from WiX or is it your own, custom GUI?
3) These machines are not Windows 11 are they?
4) Are you installing on a very clean virtual? The below entry in the stack trace makes me wonder if the Visual C/C++ Runtime is installed on the box in the appropriate version?:
msiexec!__mainCRTStartup+1a0
This would seem to refer to "The C runtime Library (CRT)". Please check if it is installed: Microsoft Visual C++ Redistributable Latest Supported Downloads.
Logging
Verbose logging with extra debugging information (very slow) - Comprehensive answer on logging:
msiexec.exe /i C:\Path\Your.msi /L*vx! C:\Your.log
Quick Parameter Explanation:
/i = run install sequence
/L*vx! C:\Your.log = verbose debug logging at specified path
The x adds extra debugging information, and the ! disables the log buffer. This means there is no lost log if there are any crashes.
Silent Installation
I am wondering if the crash comes from the setup GUI alone. If this is the case you might be able to install the setup silently successfully (since this bypasses the GUI entirely). Please try this? If this fails too, perhaps it is the Visual C/C++ runtime that is missing? Or likely something else. Logging is essential as explained above.
msiexec.exe /i c:\setup.msi /QN /L*V "C:\Temp\msilog.log"
Quick Parameter Explanation:
/L*V "C:\Temp\msilog.log"= verbose logging
/QN = run completely silently
/i = run install sequence
You can throw in the exclamation mark for continuous logging (no log buffer) here as well, but that will slow the installation down a lot.
Links:
Answer on silent installation here
Comprehensive answer on MSI logging
https://www.advancedinstaller.com/user-guide/read-log.html
I used the script found here
... And every time that I generate this dynamic package, it needs to open the script task and click "Ok" because the "The binary code for the script is not found." error aways appears. Is there a way to solve this without BIDS ? Thanks and sorry my bad english.
I got this error when a SSISDB was upgraded to 2016 from 2012 and the package was not re-deployed using newer visual studio with project set to deploy to SQL Server 2016 in the project deployment properties.
This is often caused to to an error or omission in the code in the script task. If you are certain that the code is correct you can go to the script properties and set the PrecompileiIntoBindaryCode to False, the default is set to true. This is under the Properties or in the Script option of the properties window.
This worked for us
From Project properties, change TargetServerVersion to SQL Server 2019 (Or desired version)
open the .dtsx file for each package in Notepad++ or other text editor
remove the following for each dtsx file (there will be 1 occurence per script component in packages)
<PropertyGroup>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
</PropertyGroup>
save the .dtsx file
go back into Visual Studio and rebuild the project file (as well rebuild individual script task)
I just ran into this error, after I changed my package deployment configuration to 2012. In the script some references we no longer linked. I had to reset the version of the .Net framework in the VS script environment, references were now legit, rebuild success.
In Visual Studio 2017, SSIS 2017 solution, had same error on a script task. Compared to another solution with similar process and discovered the issue was the Reference which had an error did not have a path listed for the dll. Removed the reference and added again. This resolved the issues.
Uninstall VS 2015 and SSDT 14.
Re Install VS 2015 and SSDT 14.
Open a new Integration project and import the SSIS project using the ispac file
Open the task having the error
Click On Edit Script.
Then either do this:
In Build tab click on Run code analysis on solution or Build or Clean and then Build
Save All the solution
Close the window
Click on OK in the task window.
OR just click on edit script and then OK button
The error should go off
This is for Visual Studio 2015 Community/SSDT 14
use SSMS V17.8.1 and upgrade your SSISDB and it will work, I tried it.
For me, I found that using string interpolation caused the issue.
For example:
This line caused the error:
command += $"test {property.Name}";
Changing it to this fixed the error:
command += "test " + property.Name;
After changing from VS 2017 to VS 2019, I saw this error in SQL Server / Integration Services Catalog / "My Package" / Validate... These messages are also visible in Standard Reports / All Executions.
My particular error messages were "VS_ISBROKEN" in the SSIS.Pipeline and "The binary code for the script is not found." in my scripting task.
I opened up the scripting task (C#) and changed the project target to x86 instead of None (MSIL), rebuilt it, closed the scripting solution, pressed Ok to keep the script changes, saved, built and deployed.
That worked for me.
Addendum:
It turns out that I was deploying a single package using VS2019 while the original Project was deployed using VS2017.
I think that the two deployments are not 100% compatible, and recommend that users either deploy an entire project, or deploy a package update using the same version as was used for the initial release.
You should probably ignore my suggestion above about changing project target.
Check your references, make sure all external references are added to the server's GAC.
For adding your dll(for example csvhelper.dll) in GAC you can use the following command in cmd.
C:\test>"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7 Tools\gacutil.exe" -i csvhelper.dll
**Put your dll in a folder (for example in test folder)
**Pay attention which version of .Netframework you have(Here I used .net4.7)
Steps so far:
Downloaded Reg Tool from MS
Built
Deployed on to CRM App Server (Win2k8 machine)
Loaded and signed in with Deployment Admin account
Add New Assembly
Browse to plugin library
Press Open
Error!
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'file:///C:\crmtools\PluginRegTool\PluginRegTool_1708_New_From_SDK\PluginRegistration.exe' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
The inner exception says:
System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework.
This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous.
If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
The plugin library I am loading is sitting on the same box as the PluginRegTool (the CRM App server as I said before). The regtool is under a folder on the c:\ drive and plugin library is sat under \\server\bin\assembly
Pulling my hair out with this one, must have done this 100 times before!
Any help much appreciated.
Sorted it
Right click the plugin registration tool exe file
Click properties
File has been 'blocked' - right click and press 'unblock'
Et voila!
One less stressed CRM developer!
Hope this helps someone else.
edit: worth saying that this happened again and it was the actual plugin library this time. It seems to be around transferring files from other machines causes this issue. If anyone has a more detailed explanation as to the cause, I'd love to get more information around this.
I am trying a simple code for event handling. I applied break point on a line of action script code of event. I want to see the debug window to check which event is generated. It does not show me any error but whenever i click the debug button i get the following problem
The Flash Builder debugger failed to connect to the running application.
Ensure that:
For in-browser applications, you are running the debugger version of Flash Player.
For network debugging on a mobile device, you have a reliable network connection to the device, and port 7935 is open on your machine's firewall.
My project runs correctly in browser showing the desired output but it shows me launching failed dialog with above error. Please help
One other thing you can try which worked for me when the above didn't - in Flex Compiler in Properties for the project, untick Generate HTML wrapper file, apply that, then tick it again and apply again. Seems to clean/reset the project in some way, which 'clean project' doesn't.
Try to shutdown "adl.exe" in taskmanager, It seens the old adl.exe occupied port 7935 that flashplayer can't creat new one.
That's how I solved it.
It happens many a time, but you can solve it in 4 ways
1) Clean the project and try.
2) Close flex builder and reopen it. try it, If that doesn't work than go for 3 option
3) Change your workspace and import that project in it or best is create new one and make the changes in it, Sometimes the workspace get corrupted and so it happens...
4) If above 3 option that doesn't work than reinstall your Flex builder, make sure that you uninstall flex builder properly.
I had exactly that symptom. Blank browser window, a freeze at 57% for 2 minutes and the same error message.
The problem was an error in my javascript. As usual, it just silently aborts whatever it is doing. As a result, the SWF was never started and the debugger failed to connect to the running program.
So, if the browser window remains blank it is probably a javascript error. Display the javascript console to see what is going on.
When I faced this issue what I had to do is re-install the adobe flash debugger version for firefox and Flash could successfully run in debug mode
Reason for the error : The firefox updates the flash builder version which for some reason doesn't work with the Adobe Flash Builder 4.6
You can follow below steps and get the flash application run in the debugger mode :
1) Go to https://www.adobe.com/support/flashplayer/debug_downloads.html
2) Download : [Download the Flash Player content debugger for Firefox - NPAPI][1]
3) Install the downloaded executable and install it over whatever version of Adobe Flash
builder that you have .
4) Restart the Flash Builder and run the application in debugger mode and check if it
works.
I have a complex, pre-existing Actionscript project to work with at my current employer. The project was originally created with FlashDevelop, which is not an option for me as a Mac user. I can successfully build the project and deploy it to others. It runs as expected.
The problem is with the debugging. I cannot make it work. I believe users of Flash Builder on Windows machines have successfully debugged this project on their machine. I can build and debug projects I make myself. It's THIS particular project, or something about how it is constructed, that is preventing debugging from occurring.
Symptoms:
Starting the program via the Debug button runs the program, but the presence of a breakpoint causes the program to freeze the browser where it is running
Removing the breakpoint or stopping the debugger allows the browser to unfreeze and continue normally
At no point does the breakpoint actually get reached and break into the debugger
Attempting to place a breakpoint during execution results in an internal error: java.lang.NullPointerException
Example log message from within .metadata/.log
java.lang.NullPointerException
!STACK 0
!MESSAGE Error processing debugger commands
!ENTRY com.adobe.flexbuilder.project 4 43 2011-08-24 13:35:07.404
at java.lang.Thread.run(Thread.java:680)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.run(FlexDebugTarget.java:793)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.eventLoop(FlexDebugTarget.java:732)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread$1.run(FlexDebugTarget.java:752)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.access$7(FlexDebugTarget.java:642)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.advanceStateMachine(FlexDebugTarget.java:668)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.installDeferredBreakpoints(FlexDebugTarget.java:637)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget.access$4(FlexDebugTarget.java:1006)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget.instantiateBreakpoint(FlexDebugTarget.java:1012)
at com.adobe.flexbuilder.debug.breakpoints.FlexLineBreakpoint.instantiate(FlexLineBreakpoint.java:465)
at com.adobe.flexbuilder.debug.breakpoints.FlexLineBreakpoint.findSourceFiles(FlexLineBreakpoint.java:412)
Attempted Fixes:
Cleaned project
Cleared browser cache
Tried different browsers (Yes, I have the debug player)
Deleted .metadata
Deleted workspace
Reinstalled Flash Builder
Reinstalled Debug Flash Player
Restarted Mac
Tried a different SDK
Reordered Java preference for both 32 and 64 bit configurations
Removed symlinks from project configuration (that is, symlinks are no longer needed to correctly find the build or run location)
Cleared Flash logs
Ensured no more than one version of the program was getting compiled (so it can't actually be running from another location)
Explicitly turned on debugging through compiler argument: -debug=true
Changing just about every relevant and lots of irrelevant settings within Project Properties
Project Details:
Interestingly, clicking on Actionscript Applications in the Project Properties results in Flash Builder immediately becoming unresponsive
Uses third-party libraries for functionality that may or may not be Debug builds
Uses third-party code for functionality that is included with the rest of the code via Actionscript Build Path > Source path (note that this folder must be included explicitly for this project even though the path included is already in the source directory)
Runs from a local web server, accessing local database using a custom domain that is not "localhost" nor an IP address (changed for Chrome cookie issues), rather it looks like http://programname.local/
Launch configuration starts the web browser at the correct local url (as opposed to starting up from a file), probably irrelevant
There is one additional compiler argument that simply creates a global, compile-time constant, probably irrelevant
Source and project directories contain svn repository folders and files, probably irrelevant
I have an NDA, so I can only talk about the project and its structure, I can't post code
Configuration:
Mac OS 10.6.8
Flash Builder 4 (through CS5)
Flex SDK 4.0 and 4.5.1
Figured it out. Our app uses a preloader which I had always gotten from others. I had assumed it was compiled to debug because I always got my copy from our debug server. I didn't fully understand how it worked or what it was doing.
Due to a Flash error in the preloader, this morning I was forced to compile it for the first time. Compiling it normally (as debug) I realized the problem with non-debug swfs loading debug swfs might apply here.
Breakpoints worked as expected once I correctly compiled the preloader and fixed its bug. Apparently our preloader is doing the actual loading of the main app. Flash Builder apparently can't handle this setup (non-debug loading a debug swf), whereas FlashDevelop apparently can.
Have you tried restarting your Mac?
I feel your pain, and your list of attempted fixes are what I'd try first :)
I had a similar situation to this and after hours of cursing Adobe I restarted my Mac and that solved it (probably some kind of memory error).