URGENT! System freeze on J1900 (Bay Trail) under Win8

URGENT! System freeze on J1900 (Bay Trail) under Win8

Today I report a major bug!
On J1900 (Bay Trail) and Win8.1 the system freeze when running encode and decode simultanously in system memory mode. The kernel dump shows igdkmd64 "hanging" at DPC level for too long time. After the specific ticks expired (here 0x00001e00) the timer irq throws a bug check: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED (see below)

We have tested multiple boards (SuperMicro, Advantech,... ) all show the same error.

The error is only

  • in hardware mode (-hw). Software mode works fine(but slow).
  • in system memory mode. D3D9 and D3D11 modes works fine, but we need the decoded pictures for further processing in system memory so D3D modes are NO option!
  • on J1900 (Bay Trail).

We need this bug fixed as soon as possible.

System information:
CPU: Intel(R) Celeron(R) CPU J1900 @1.99GHz 1.99GHz (Bay Trail-D)
Mainboard: Supermicro X10SBA-L
Chipset: Bay Trail Host Bridge
Southbridge: Bay Trail LPC Bridge
RAM: 8GB (7.88GB usable)
Operating system: Windows Embedded 8.1 Industry
GraphicsDriver: Intel(R) HD Graphics Date:5/17/2014 Version:

Reproducing the error:
It's easy to reproduce the error with the Intel Media SDK samples (sample_ecode and sample_decode), you just had to modify these samples a little bit.
First: they must run in an endless loop, second: reduce (remove) the file write output in sample_decode (for more performance, makes the error appear faster).

=>changes in sample_encode:
    just reload the first frame of the file in LoadNexxtFrame() - for endless encoding
        sample_utils.cpp / mfxStatus CSmplYUVReader::LoadNextFrame(mfxFrameSurface1* pSurface) - insert in line 138
            fseek(m_fSource, 0, 0); // DBG - reload first frame, for endless loop       

mfxStatus CSmplYUVReader::LoadNextFrame(mfxFrameSurface1* pSurface)
    // check if reader is initialized

    mfxU32 nBytesRead;
    mfxU16 w, h, i, pitch;
    mfxU8 *ptr, *ptr2;
    mfxFrameInfo* pInfo = &pSurface->Info;
    mfxFrameData* pData = &pSurface->Data;

    mfxU32 vid = pSurface->Info.FrameId.ViewId;

    // DBG - reload first frame  only for endless loop
    fseek(m_fSource, 0, 0);

=>changes in sample_decode:

    set video wall mode for endless loop
        in pipeline_decode.cpp / mfxStatus CDecodingPipeline::RunDecoding() set m_bIsVideoWall=true and a huge m_nTimeout
        (you CAN NOT do this in the command line, because when you specify -wall in the command line the decoder switches to D3D output but he   MUST run in SYSTEM MEMORY to show the error!!!!)

            mfxStatus CDecodingPipeline::RunDecoding()
                mfxSyncPoint        syncp;
                mfxFrameSurface1    *pmfxOutSurface = NULL;
                mfxStatus           sts = MFX_ERR_NONE;
                mfxU16              nIndex = 0; // index of free surface   
                CTimeInterval<>     decodeTimer(m_bIsCompleteFrame);
                time_t start_time = time(0);

                //DBG - force endless loop
                m_bIsVideoWall = 1;
                m_nTimeout = 0x80000000;

    remove file output / no write of decode frame
        comment in pipeline_decode.cpp / line 965
            //DBG no write sts = m_FileWriter.WriteNextFrame(pmfxOutSurface);

now just start encode and decode

sample_encode.exe h264 -u speed -hw  -i input.yuv -o output.h264 -w 1280 -h 960
sample_decode.exe h264 -i inputfile.h264 -hw -o sample_out.h264

and after a short time (max. some minutes) system will freeze!!!!! And after 2 min the bug check appears:







ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre

LAST_CONTROL_TRANSFER:  from fffff80120399b2c to fffff80120359fa0

fffff801`21ccac98 fffff801`20399b2c : 00000000`00000133 00000000`00000001 00000000`00001e00 00000000`00000000 : nt!KeBugCheckEx
fffff801`21ccaca0 fffff801`202b9f85 : fffff801`21ccae70 00000000`00000000 ffffcf81`c4e44900 fffff800`5b7dc2e4 : nt! ?? ::FNODOBFM::`string'+0x2f67c
fffff801`21ccad30 fffff801`209977b5 : 00000000`00400a02 fffff801`2089efe0 fffff801`208885d4 00000000`00009101 : nt!KeClockInterruptNotify+0x95
fffff801`21ccaf40 fffff801`202d5363 : fffff801`21ccaf60 00000000`00000008 fffff801`21ccaf50 00000000`00000010 : hal!HalpTimerClockIpiRoutine+0x15
fffff801`21ccaf70 fffff801`2035b42a : fffff801`209e3800 00000000`00000000 ffffcf81`c57ee501 00000000`00000000 : nt!KiCallInterruptServiceRoutine+0xa3
fffff801`21ccafb0 fffff801`2035b80f : 00000000`0b9beb10 ffffe001`eef6d000 00000000`00000000 00007ff9`1ab014aa : nt!KiInterruptSubDispatchNoLockNoEtw+0xea
ffffd000`21878210 fffff800`5b77e9f2 : fffff800`5b77e867 00000000`00000000 ffffe001`eef6d000 00000000`00000000 : nt!KiInterruptDispatchLBControl+0x11f
ffffd000`218783a8 fffff800`5b77e867 : 00000000`00000000 ffffe001`eef6d000 00000000`00000000 00000000`00000000 : igdkmd64+0x1119f2
ffffd000`218783b0 fffff800`5b727f74 : ffffe001`eef6d000 ffffe001`eef6d000 00000000`00000000 00000000`00000000 : igdkmd64+0x111867
ffffd000`218783f0 fffff800`5b7275e2 : 00000000`00000101 fffff801`00000000 00000000`00000000 00000000`00000000 : igdkmd64+0xbaf74
ffffd000`21878450 fffff800`5b6c85d9 : 00000000`00000001 ffffe001`ec827300 ffffcf81`c55def00 fffff800`59f7ac8f : igdkmd64+0xba5e2
ffffd000`218785d0 fffff800`5b6e1710 : ffffcf81`c55def90 fffff801`202eaec8 ffffcf81`c55def90 fffff800`59f70ce9 : igdkmd64+0x5b5d9
ffffd000`21878600 fffff800`5b73857e : 00000004`c89c02ef 00000004`c89c02ef ffffd000`218789b0 ffffcf81`c57ee540 : igdkmd64+0x74710
ffffd000`21878630 fffff800`5b717fee : 00000000`00000001 ffffcf81`c55def90 ffffd000`21878cc0 fffff801`20885791 : igdkmd64+0xcb57e
ffffd000`21878660 fffff800`5b68f158 : ffffcf81`c55def90 fffff800`00000000 fffff800`5b29e089 fffff800`59f7a911 : igdkmd64+0xaafee
ffffd000`21878690 fffff800`5b32f570 : ffffd000`218788a8 ffffcf81`c57ee540 ffffd000`21878cc0 ffffd000`21878cc0 : igdkmd64+0x22158
ffffd000`21878700 fffff800`5b2fca2d : ffffcf81`c57ee540 ffffd000`21878cc0 ffffc000`cb599000 fffff800`59f7a50e : dxgkrnl!DXGADAPTER::DdiEscape+0x48
ffffd000`21878730 fffff960`0025bf8f : 00000000`00000000 ffffe001`ef5bc880 00000000`0baf2660 00000000`0b83ba20 : dxgkrnl!DxgkEscape+0x57d
ffffd000`21878bf0 fffff801`203657b3 : ffffe001`ef5bc880 ffffe001`ef5bc880 00000000`0badae90 ffffc000`cb599000 : win32k!NtGdiDdDDIEscape+0x53
ffffd000`21878c40 00007ff9`1ab014aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0c13e5a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff9`1ab014aa

I can't debug further because I don't have the .pdb file of the Intel Graphics driver. But it looks like a dead lock @DPC level.



Modified files for sample_encode and sample_decode.



In theweb interface I can't change the speech from german to english. There is only german in the drop down combo.

Syntax highlightning <pre class="brush:cpp"> does not work for me






16 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

Thanks for this report.  We're looking into it and will get back to you soon.

Ritratto di Tony Pabon (Intel)
Best Reply


We believe this is likely an issue that was fixed recently.  The drivers with fix have not yet been fully tested.  I will make sure this method of producing the issue is known, and I will update you with driver availability.

Thank you for the detailed reporting.


That sounds good.

Is there any chance to provide me a beta version of the driver?  That will be enough for our test department to go on testing. Recently all test are stopped because of this bug.

Greetings Carsten

Hi Tony,

just to bring it up again, Do you have a beta driver version for me? I have seen a windows 8.1 beta driver for Intel HD graphics in the Intel driver download section. It is the version But this driver does NOT install on J1900 platforms. During installation a message pops up, wich says something like:invalid platform or platform not supported.

It is really URGENT! I need a working driver (a beta version would be enough) because the current driver does not run longer than 2 minutes without producing a BLUE SCREEN OF DEATH!!!

Hope to hear from you soon


greetings carsten





I tried the Intel NUC drivers 8/13/2014. Version: but system still freeze after seconds!!!

There is still a little hope, that we will get "non-freezing" drivers in the future from Intel...

regards carsten





Ritratto di Tony Pabon (Intel)

This important issue is escalated and we are working to understand why you are seeing this behavior.

I'll update this thread with more information soon.


I have some more hint for your devellopers:

I figured out, that for reproducing the error it is enough to start just more than one decoding process (you do not need start encoding). In other words: just start the sample_decode.exe twice from command windows ( dont forget to use diffrent output files)

sample_decode h264 -hw -i  test.h264 -o out1.bin

sample_decode h264 -hw -i  test.h264 -o out2.bin

and system will freeze after a short time (max. some minutes)

System does NOT freeze when i start multiple decoding threads, it MUST be more than one  process.

I really hope you will fix this soon




Carsten K. schrieb:
I figured out, that for reproducing the error it is enough to start just more than one decoding process

It seems that you have the same problem as described here: https://software.intel.com/en-us/forums/topic/475624?page=1#comment-1778985

I think you should not expect a quick fix :)

A new observation,

the system freeze depends on the input stream. Some streams (espacially all streams generated/encoded by the intel Media SDK does NOT freeze the system), while other freeze it after some seconds.

I will provide you a stream that will force a system freeze in a PM

This problem must be fixed soon, we had to handle lots of industrial IP cameras, with lots of diffferent streams, and that the decode of a regular "norm confom" h264 video stream that freeze the system is UNACCEPTABLE. Intel media SDK is UNUSABLE at the moment and a security risk for ALL windows plattforms.

Hope u will handle this issue with HIGH PRIOTRITY



Ritratto di Harsh Jain (Intel)

If you can provide us specific input stream that is forcing your system to freeze. We will look into the issue and escalate it further. 

We will update the thread with more information.



are there any news? Can you (your developer)reproduce the problem?

I reported this bug 2 month ago!!! System still freeze. MediaSDK is still UNUSABLE on J1900 (Baytrail) platforms.


Ritratto di Tony Pabon (Intel)


We understand the desire for a fix.  Yes we reproduce the issue on this specific platform (issue does not occur on many other platforms) and engineers have been working on the issue.  The issue continues to be 'escalated' and it is reasonable to expect a fix available soon.

Ritratto di Tony Pabon (Intel)

:Hi Carsten,

I know the fix for this issue was fairly complex and was being tested, but I have yet to hear if a driver with the fix is available to us.  I am requesting status.


Hi Tony,

now (6 month later) i still did not get any positive feedback/response from you, if a driver will be available soon and when. It would be nice, if you report the current status in this forum. I still have a little hope, that a driver will be available this year (even I still wonder that Intel was not able to fix it in the last 6 month).

I have seen, that there is a new driver for Intel Iris and  HD graphics  (12/Jan/2015) but this driver does not install on Celeron J1900 (Baytrail) platforms.

  • Dateiname: win64_153614.exe
  • Version: (News)
  • Datum: 12.01.2015
  • Größe: 116,28 MB
  • Sprache: Mehrsprachig
  • Betriebssysteme: Windows 7 (64 bit)*, Windows 8, 64 bit*, Windows 8.1, 64 bit*


But the driver for J1900 Cleron is still from 7 April 2014!


This problem is really very very urgent! Our production with J1900 CPUs is freeezed atm. !!!

Regards Carsten




Hi Crasten, 

We are investigating why new drivers did not become available for Celeron/Pentium but was available for tablets and 3rd Generation Core Processor. We think it is just a mistake, the drivers posted for those other 3rd generation devices should also support J1900 baytrail. you can get that from here and here. Thank you for your patience. 


Accedere per lasciare un commento.