PowerShell Script execution hangs in Windows Server 2012R2 - windows

One of my script hangs during one of our product installation. Hangs is happening while executing some of the common PowerShell and native ExEs from PowerShell.
more details in below question which is actually logged in Windows PowerShell Forums.
we use msdeploy,iisreset,appcmd here during web packages installation, this is the place where it hangs, but hang happens after successful execution of msdeploy.exe. I tried using latest available version of msdeploy, is still hangs some times.
We have around 7 web packages, hang happens after deploying a package as well as before deploying a package.
Code logic here.
Step 1: Test msdeploy exists, if not install it
Step 2 : iisreset (hangs here sometimes)
Step 3 : check if the app pool is available, if so Stop-WebAppPool (hangs here sometimes)
Step 4: install web package using msdeploy
Step 5: get the app pool state and start if it is not started – (some times hangs here)
Step 6: do some app pool settings using appcmd.exe (hangs some times after this execution)
Step 7: some other app pool settings like Set-ItemProperty IIS:\AppPools\$appPoolName -Name recycling.periodicRestart.memory -Value $appPoolRestartMemory
Step 8 : get the next package and go to Step 1
Sometimes, hang happens after executing
netsh http delete urlacl url=$url
Note: None of the hangs are consistent, each and every time, hang happens in either one place.
I did procdump analysis of the powershell process and ended up in ntdll!ZwWaitForMultipleObjectsroutine for all hangs.
same is being shown by the proc explorer threads view as well.
PFB the hanging handle's stack
ntdll.dll!ZwWaitForMultipleObjects+0xa
KERNELBASE.dll!WaitForMultipleObjectsEx+0xed
clr.dll!GetMetaDataPublicInterfaceFromInternal+0x3a95e
clr.dll!GetMetaDataPublicInterfaceFromInternal+0x3a7f8
clr.dll!GetMetaDataPublicInterfaceFromInternal+0x3a5f1
clr.dll!GetMetaDataPublicInterfaceFromInternal+0x3eeb5
[Managed to Unmanaged Transition]
mscorlib.dll!System.Threading.WaitHandle.InternalWaitOne+0x21
mscorlib.dll!System.Threading.WaitHandle.WaitOne+0x31
System.Management.Automation.dll!
System.Management.Automation.Runspaces.PipelineBase.Invoke+0x34
Microsoft.PowerShell.ConsoleHost.dll!
Microsoft.PowerShell.Executor.ExecuteCommandHelper+0x154
Microsoft.PowerShell.ConsoleHost.dll!
Microsoft.PowerShell.ConsoleHost.DoRunspaceInitialization+0x7ed
Microsoft.PowerShell.ConsoleHost.dll!
Microsoft.PowerShell.ConsoleHost.DoCreateRunspace+0x1d3
Microsoft.PowerShell.ConsoleHost.dll!
Microsoft.PowerShell.ConsoleHost.CreateRunspace+0x49
Microsoft.PowerShell.ConsoleHost.dll!
Microsoft.PowerShell.ConsoleHost.DoRunspaceLoop+0xc3
Microsoft.PowerShell.ConsoleHost.dll!
Microsoft.PowerShell.ConsoleHost.Run+0x14c
Microsoft.PowerShell.ConsoleHost.dll!
Microsoft.PowerShell.ConsoleHost.Start+0x1aa
Microsoft.PowerShell.ConsoleHost.dll!
Microsoft.PowerShell.UnmanagedPSEntry.Start+0x33c
[Unmanaged to Managed Transition]
clr.dll!DllCanUnloadNowInternal+0xbe3
clr.dll!DllCanUnloadNowInternal+0xaa3
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x1abde
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x1aa87
[Managed to Unmanaged Transition]
mscorlib.dll!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal+0x80
mscorlib.dll!System.Reflection.RuntimeMethodInfo.Invoke+0x92
[Unmanaged to Managed Transition]
clr.dll!DllCanUnloadNowInternal+0xbe3
clr.dll!DllCanUnloadNowInternal+0xaa3
clr.dll!DllCanUnloadNowInternal+0x12f5
clr.dll!SetRuntimeInfo+0x20b4
clr.dll!SetRuntimeInfo+0x1c16
clr.dll!SetRuntimeInfo+0x253d
clr.dll!SetRuntimeInfo+0x2906
clr.dll!SetRuntimeInfo+0x276d
clr.dll!SetRuntimeInfo+0x26ae
powershell.exe+0x8663
powershell.exe+0x7c67
powershell.exe+0xa6cc
KERNEL32.DLL!BaseThreadInitThunk+0x22
ntdll.dll!RtlUserThreadStart+0x34

Related

Cannot launch MinGW-built program in WinDbg: "No runnable debuggees error in 'g'"

I'm trying to debug a program in WinDbg. However, WinDbg won't run it after I launch it; after loading the binary, when I attempt to continue the program I get this error:
0:002> g
^ No runnable debuggees error in 'g'
Some relevant facts:
I'm using Windows 10.
The program in question is written in C and was built with MinGW.
The program is loaded, as I see it in the Task Manager. It just won't go beyond ntdll!NtWaitForWorkViaWorkerFactory.
There is no error in the program at this point; I'm just trying to get the thing running before I move on to my real problem (which is beyond the scope of this post).
I can attach to a running instance of this program just fine, I just can't launch new ones.
I can launch notepad.exe with WinDbg just fine.

"The process cannot access the file 'Default.rd.xml' because it is being used by another process." on AppVeyor CI

I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.

Distracting Exception output in QtCreator when debugging Windows application

I am using QtCreator 4.1rc1 under Windows with the msvc tool chain. The debugger is cdb from the Windows 8.1 SDK. I had the same issue with older versions of QtCreator.
When I debug my application, then there are many messages to the output (and issues) pane in the form
Exception at 0x773596c2, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance) in WinSCard!SCardTransmit
I understand, that this is to be expected under Windows and those exceptions are actually not a problem. But they pollute the output and issues pane and basically render them useless.
So I tried to get rid of the messages. But failed after hours trying. What I tried is the following:
Use the check box 'Ignore first chance access violation' under Tools->Options->Debugger->CDB
Specifying command line arguments to cdb.exe: -xi
Create a script file for cdb.exe to be used at startup to avoid the warnings. The script contained the commands 'SXI 8010000a; SXI 0000071a; SXI e06d7363'. I tried placing the script in several directories and also specifying it with the command line options -cf or -cfr.
When I run cdb.exe from a command line using the startup script, it works! No exceptions are printed to the console. But when I start it from QtCreator, they are there again.
I assume, that QtCreator is using their own startup scripts and those overwrite the ones I specified.
Has anyone succeeded in hiding those exception outputs under QtCreator with cdb?

MS Test hangs when tried to execute the tests without installing visual studio

To execute the tests using MSTest I have already copied required dlls to specific folder.
It is not giving me any exception.
Added logging to MsTest.exe.config though no logs are generated in a file mentioned MSTest.exe.config.
Command is:
C:\01Jenkins\MsTest\MSTest.exe /testcontainer:"C:\abc.dll " /resultsfile:C:abc\TestResults\testresult2.trx /category:"xyz"
Loading C:\abc.dll...
Starting execution...
It gets stuck at the above point
Any type of solution would be appreciated.

XCode doesn't run or even install project on device

I'm working on an iOS project in Xcode 6.1 (which includes an app extension, in case that's relevant). When I try to run the project on Xcode, however, it doesn't actually run the project -- it just says its finished running seconds after "Running [My target]" appears in the Xcode window's toolbar. A (2) in a grey circle appears to the left of the running text before the app "finishes," on successful runs there is usually a (3).
If I delete the app from the device and try to build and run it again, Xcode claims that it finished running without ever installing it in the first place.
In the console of my computer, I can see the following messages:
10/23/14 9:56:33.045 AM Xcode[86586]: AMDeviceSecureInstallApplicationBundle (thread 0x11e05f000): no old package to delta against, falling back to old skool install
10/23/14 9:56:33.045 AM Xcode[86586]: AMDeviceSecureInstallApplicationBundle (thread 0x11e05f000): Blasting the bundle over to the device in an old skool way
10/23/14 9:56:37.949 AM Xcode[86586]: AMDErrorForMobileInstallationCallbackDict (thread 0x11c59e000): GOT AN ERROR 0xe800003a
10/23/14 9:56:37.956 AM Xcode[86586]: SZConduit: _MonitorResultDispatchFunction:140 (0x0x11c59e000): Got error from service: InstallationFailed
10/23/14 9:56:37.956 AM Xcode[86586]: _AMDeviceTransferAndInstall (thread 0x11e05f000): SZConduitSendPathWithPreflight failed: 0xe8008017
10/23/14 9:56:37.960 AM Xcode[86586]: writeDictToFile:1258 ==== Successfully wrote Manifest cache to /var/folders/yt/lbzml8ns3f5dfg7chpk14s2h0000gp/C/com.apple.DeveloperTools/6.1/Xcode/af8b53723f8db55690c776f7ae336036/2031be7d6eb56fd1d8e5c85034f9500facb31def/ManifestCache.plist
10/23/14 9:56:37.961 AM Xcode[86586]: AMDeviceSecureInstallApplicationBundle (thread 0x11e05f000): returning 0xe8008017
No one else working on this project has this issue. Occasionally I see an error message with something like "Can't run, a signed resource is missing or has been altered," but this is pretty rare.
I've tried reinstalling Xcode, this does nothing.
Deleting Derived data fixes the issue, but I have to delete it after every run or the problem reappears. This is pretty inconvenient, so I'm looking for a more permanent fix.

Resources