Develop Reference

Is it possible to run Kinect V2 inside a Docker container?

I'm exploring the feasibility of running a C# Kinect Visual Gesture Program (something like Continuous Gesture Basics project https://github.com/angelaHillier/ContinuousGestureBasics-WPF) inside of a Docker for Windows container.
Is this even theoretically possible (run C# Kinect in a Docker for Windows container?)
If the answer to 1 is yes, here are some extra details:
I'm using the microsoft/dotnet-framework:4.7 image as a basis and my initial Dockerfile looks like this:
FROM microsoft/dotnet-framework:4.7
ADD . /home/gesture
WORKDIR /home/gesture
Build the image:
$ docker build -t kinect .
Turn on container:
$ docker run -dit --name kinectContainer kinect
Attach to a powershell session to monkey around:
$ docker exec -it kinectContainer powershell
When I attempt to run my gesture application from the Docker container I get the following error (which is expected since no Kinect SDK was installed in the container):
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'Microsoft.Kinect, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependenc
ies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ---> System.BadImageFormatExcep
tion: Cannot load a reference assembly for execution. erable program. Check the spelling of the name, or if a path was included, verify that the path
--- End of inner exception stack trace ---
at GestureDetector.GestureDetectorApp..ctor()
At this point, the big question is how to install the Kinect v2 SDK [KinectSDK-v2.0_1409-Setup.exe] or the Kinect v2 runtime [KinectRuntime-v2.0_1409-Setup.exe] in the container.
The installers have a EULA and according to some clever University of Wisconsin folks, there is a technique to to extract installers using Wix's dark.exe decompiler(https://social.msdn.microsoft.com/Forums/en-US/a5b04520-e437-48e3-ba22-e2cdb46b4d62/silent-install-installation-instructions?forum=kinectsdk)
ex.
$ & 'C:\Program Files (x86)\WiX Toolset v3.11\bin\dark.exe' C:\installerwork\KinectRuntime-v2.0_1409-Setup.exe -x c:\installerwork\kinect_sdk_installersfiles
The issue I ran into when I got to the underlying msi files is there is no option to run them silently using msiexec.
I've figured out that the runtime installer (Runtime installer (KinectRuntime-x64.msi) extracted from the Kinect v2 SDK) makes at least the following changes in the filesystem:
Creates a folder "Kinect" in C:\Windows\System32 and adds 3 files to System 32:
k4wcll.dll
kinect20.dll
microsoft._kinect.dll
The last three files in System32 should be the 64-bit versions (the installer appears to have x86 and x64 versions of those 3)
Replicating those changes by hand does not lead to success on the host machine let alone in the container.
It's currently unclear what other registry/system changes are occurring with the installer (and whether or not that would get us over the goal line in the Docker container)
Any ideas about how to proceed from here?

In short no. docker on windows does not have the ability to hardware tunnel/map. on Linux, it does via the --device= option
As #VonC has stated you will need to use a Windows VM this could be Hyper-V or you can use Virtual Box then you can provide the Kinect Hardware via the Tunneling method (add/connect device), without this there would be no way for your container be that VM or not to access the hardware of the host machine with windows.

Another approach would be to try and install Kinetic in a Windows server VM, and detect the exact changes brought by said installation.
See for instance "How can I find out what modifications a program’s installer makes?" and a tool like ZSoft Uninstaller 2.5.
Once you have determined exactly what files/registry/variables are impacted by the installation process, you can replicate that in a Dockerfile.

How to generate a memory heap dump from a running C# mono application?

I have a Mono application running under Mono JIT compiler version 3.2.8 (Debian 3.2.8+dfsg-4ubuntu1.1) with --debug enabled. After quiet some time, I get quiet unexpected memory usage.
I know there is HeapShot but it generates over 4GB of output even before the problem gets real. In addition the UI tool can not load more than ~17 of the included Snapshots before running out of memory while loading the Dump.
That's why I'm looking for a way to produce a single Heap dump of my application when the memory usage grew big. Is there any way?
An alternative would be to get better tooling to load single snapshots from a huge generated HeapShot dump.
Any hints how to find the memory leak would be helpful, too.
Thanks.

run in first terminal, it will not produce dump until command "heapshot" sent
mono --debug --profile=log:heapshot,heapshot=ondemand,time=fast,port=7103,output=%p.mlpd MyApp.exe
to obtain heapshot ondemand run in second terminal to send command "heapshot"
echo -n "heapshot\n" | nc localhost 7103
You need to install netcat package from your distro

What are .ni.dll and .ni.exe files in a minidump?

I got a minidump from the Windows Store Apps submission process (sent by a reviewer) because of a crash in my app. I am having problems loading the symbols for my app, because the error occurs inside App.ni.exe, a file which I don't know where comes from.
My app only has a App.exe (and some DLLs), but the dump keeps referring to .ni.dll and .ni.exe. These files are nowhere to be found in my .appx or .appxsym files.
My app is built for each specific platform (x86, x64, and ARM). It is the x64 version that crashed in the stackdump.
My current attempts with windbg:
Symbol path:
Srv*C:\Users\Vegard\Appdata\local\temp\SymbolCache*http://msdl.microsoft.com/download/symbols`
Windbg attempt:
0:006> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
Unable to load image Newtonsoft.Json.ni.dll, Win32 error 0n2
*** WARNING: Unable to verify checksum for Newtonsoft.Json.ni.dll
*** ERROR: Module load completed but symbols could not be loaded for Newtonsoft.Json.ni.dll
Unable to load image App.ni.exe, Win32 error 0n2
*** WARNING: Unable to verify checksum for App.ni.exe
*** ERROR: Module load completed but symbols could not be loaded for App.ni.exe
Unable to load image mscorlib.ni.dll, Win32 error 0n2
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
Update: Trying to ngen App.exe (running as admin) I get the following error:
> ngen.exe install App.exe
[snip]
This operation is only valid in the context of an app container.
(Exception from HRESULT: 0x8007109A)
What is an app container in this case? Where should I run it from?
Update: After a long while troubleshooting, and figuring out the root cause through other means, I have concluded that the minidump file I got was missing this information. No matter of coaxing could get the debugger to load the symbols for the files.

Take a look at the tool description Ngen.exe (Native Image Generator):
The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.
Keep in mind this processor-specific machine code.
If you need to debug minidump with NI images you need to get symbols (PDBs) for these images. The PDBs for managed DLL will not work, you need to generate Native PDB for NGEN'd image with NGEN tool, take a look on the article Creating NGEN PDBs for Profiling Reports. This article about how to get NGEN pdbs for Profiler Report, but for debugging it is the same.
As I said keep in mind that NGEN is a processor-specific machine code, so to generate PDBs for them:
Since NGEN’d images are native, it’s important you use the copy of ngen.exe that matches the architecture of the application you are profiling (x86/x64/ARM). For example if the application is running 64 bit on Windows 8 RTM then you would need to reference the copy of ngen.exe in “C:\Windows\Microsoft.NET\Framework64\v4.0.30319”
UPDATE:
From the link above:
if you remote profiled a Windows Store App, you have to do this on the machine you were running the app on while you were profiling. It will not work if you do it on the machine you are viewing the report on
So it looks like you need to generate ngen modules / pdbs on the same machine where you got the minidump.
Windows has a Native Image Service, which generates ni images for Windows Store Applications after some time when you install it on your machine. You can try to use procmon.exe to find how Windows generate ngen modules for applications from Windows Store. (just use filter for Process Name with ngen.exe).

NI=Native Image. In other words, NGEN'd images as the comments above indicate.

it is possible to get the crash details of a application that triggers Microsoft Windows Error Reporting?

I have an application written in C#. This application is locking by windows, return something like: "The xxx application has stopped working".
Is it possible to get the reason for this crash? I tried using try{} catch{} throughout the application without success. It works on my computer, but not on my friend's computer.
Both computers have same configuration:
Windows seven 7 ultimate 32 bits
Processor:2.13ghz
memory ram: 2gb
UPDATE
Well, in the event log of computer of my friend I found some details of the crash:
Faulting application name: xxxx.exe, version: 1.0.0.0,time stamp:0x4eb5e63a
Fault Module Name:KERNELBASE.dll, version: 6.1.7600.16850, time stamp:0x4e21132b
Exception Code:0xe0434352
Identification of the process that failed: 0x26c
Start time of the faulting application: ...
Faulting application path: ... \xxx.exe
Path F module failures: C:\Windows\system32\KERNELBASE.dll
Report ID: xxxxx-yyyy-dddd-dddd-aaaaaa
UPDATE 2
Finally,I found the function that is causing the exception.
handling the function with try {} catch (Exception Err) {} I found some details of exception:
Err.Message:The device is not ready
Err.Source: mscorlib
how can I fix it?

"Works on my machine" is a very common problem with a myriad of causes. Generally the reason is that something is different between the two machines. Some easy things to rule out:
is your friend's computer a development machine, with Visual Studio installed?
does your application rely on a particular path (for example, a D: drive), a database, a service, a COM component, or something else that an install package should be including?
has your friend configured UAC differently from you? Does one of you sign on as the account Administrator, while the other uses another account that is in the Administrators group?
did you test a debug version on your friend's machine? debug versions usually aren't redistributable
did you test version x of the exe and version y of some class library, forgetting that you made a change to one of them yesterday?
do you and your friend have different versions of IE, Office, or some other component that may be used by the app? Do you have different IE settings (eg proxies?)
are the two computers both completely caught up on updates and service packs?
is the application trying to access some hardware (microphone, web cam) that is not on your friend's machine or is importantly different between the two machines?
The literal answer to your question is yes, you can sign up for something called Windows Error Reporting and get the reports that the dialog says it is collecting. However I sincerely doubt that you want them. You should have all the information you need to find the error right where you are. Concentrate on what is different (even if you think it's irrelevant) between the two machines.

Most likely it is a missing dependency. Double check to make sure that your program is installing all of the Dll's that it needs. I have run into similar problems usually with an .ocx file not being properly registered or not present.
As far as your question goes try using the MDbg.exe file from the .Net Framework SDK or Visual Studio. Microsoft also has other debugging tools available.

MPIexec.exe Access denide

I have installed microsoft compute cluster and MPI.net, now i have trouble to run program using mpiexec.exe on cluster. When i try to run it on console i get message: "Access Denied", and pop up: "mpiexec.exe is not valid win32 application".
I tried google it, but found nothing. Pls help. :)

Usually that means that you're attempting to run an x64 binary on an x86 platform. Is this likely what is happening?