Docker Image Creation using builder fails, but running same steps using 'docker run' works?

I try to create a docker image for a TAPI-Service using the builder but a setup I call always hangs.
When I start “docker run microsoft/windowsservercore”, and then execute the same steps, then it works as expected.
Any idea what could be wrong, what I could check?

Issue Type: Image creation using builder fails, same steps using ‘docker run microsoft/windowsservercore cmd’ work
OS Version/build: Windows Server 2016
App version: docker 17.06.1-ee-2
Steps to reproduce:
1.) from extracted to c:\temp\docker\tapi and changed for Silent as descried
2.) this runtime is needed: saved to c:\temp\docker
3.) This DockerFile for the builder saved as c:\temp\docker\Dockerfile:


FROM microsoft/windowsservercore
RUN "dism /online /add-package /packagepath:C:\Windows\servicing\Packages\Microsoft-Windows-Singulus-ServerCore-Tapi-Package~31bf3856ad364e35~amd64~en-US~10.0.14393.0.mum /packagepath:C:\Windows\servicing\Packages\Microsoft-Windows-Singulus-ServerCore-Tapi-Package~31bf3856ad364e35~amd64~~10.0.14393.0.mum"
COPY vcredist_x64.exe c:\Temp\vcredist_x64.exe
COPY tapi c:\Temp\tapi
RUN c:\temp\vcredist_x64.exe /q /l c:\temp\log.log
RUN c:\temp\tapi\bin\x64\setup.exe

From what I found out by my tests so far is, that it seems to be releated to the dism - command.
When I execute only the two copy and the vcredist_x64.exe from the builder and then call the dism + setup.exe using a ‘docker run’, then the installation is quick and work.
But when I then call the dism + setup.exe using builder, then depending if it are two lines, then the setup.exe hangs, when I do it in one line, then the setup completes, but seems to be corrupt.
Also when I call the dism using the builder and then the setup.exe using ‘docker run’ then the setup hangs.

Another test I did, I executed the dism + setup + called a testapp -> output of the Testapp showed that it worked.
After that I started this image using ‘docker run’ and called the test-app again, and the Testapp showed that tapi didn’t work anymore.

So in the end it looks to me like the builder removes vital data added using the dism command

is the dism command trying to access the UI. which wont be available inside the container

is the dism command trying to access the UI. which wont be available inside the container
No, the Dism command by itself isn’t the Problem.
The Problem is that f the Docker builder extracts the changes from the Dism-command, then something get’s lost, and after that TAPI doesn’t work anymore.
So my current workaround is that I put the Dism-command(+ calling the TAPI-driver setup.exe) into a script witch I execute when starting the container.