none
Wince6.0打開共享目錄的困惑 RRS feed

  • 問題

  •         現在使用USB wifi cardCE6.0下和WINXP之間進行網路共用。
            當前遇到的問題是一旦XP共享目錄裏面有可執行檔(.exe)存在,如果雙擊打開此檔夾,CE系統會當機大概接近1分鐘(滑鼠、鍵盤都沒有反應),再次打開此目錄則不會出現當機。
    共享目錄包含其他的格式也沒有此問題。如果直接把此共檔夾複製到本地再打開也沒有問題!

            這種當機情況只會出現在CE6.0下,CE5.0則沒有這種問題。 
            文檔格式對底層的驅動應該是無關的啊,為何傳輸exe的時候會當機呢?
        CE6.0
    5.0對此的差別到底在哪里呢?

    困惑了我N久的問題希望得到各位的指點.......
    2009年2月20日 上午 01:24

解答

  • 所以 system 實際上並沒有 hang住,只是被 blocking 住, 之後就又恢復正常?
    ->  那應該是在 browsing Executable file 時, 因為要 Load ICON 所導至的延遲, 而因為 第二次 Icon 被 cache 住, 所以就不會再重 load Icon
        ->假如是這個情況 先試看看 不要用 eplorer.exe 來 browsing 該 shared folder (比如說用 net view command) 是不是就不會 lag? 
        ->或是試看看假如是用 explorer list view (small icon) 是不是會改善?

        有沒有試看看 假如是用 Ethernet 是不是就比較好? 另外該 WLAN 在 small packet 的效率是不是也會不太好?

    explorer 的 source 在 PUBLIC\SHELL\OAK\HPC\
    處理 Icon Cache 的 code 在 PUBLIC\SHELL\OAK\HPC\CESHELL\API\iconcache.cpp

    另外也可以看一下 SHGetFileInfo (PUBLIC\SHELL\OAK\HPC\CESHELL\API\api.cpp), 試看看假如在 get Icon 時是 UNC 就讓它傳回 Default Icon 看看是不是會改善

    -----------------------------------------------------------------------
    假如我的回答有確切的回答你的問題,請不嗇把它標示成"有用",謝謝
    • 已提議為解答 JocoboNY 2009年2月24日 上午 08:20
    • 已標示為解答 bauannModerator 2009年2月27日 下午 04:02
    2009年2月20日 上午 07:06

所有回覆

  • 所以 system 實際上並沒有 hang住,只是被 blocking 住, 之後就又恢復正常?
    ->  那應該是在 browsing Executable file 時, 因為要 Load ICON 所導至的延遲, 而因為 第二次 Icon 被 cache 住, 所以就不會再重 load Icon
        ->假如是這個情況 先試看看 不要用 eplorer.exe 來 browsing 該 shared folder (比如說用 net view command) 是不是就不會 lag? 
        ->或是試看看假如是用 explorer list view (small icon) 是不是會改善?

        有沒有試看看 假如是用 Ethernet 是不是就比較好? 另外該 WLAN 在 small packet 的效率是不是也會不太好?

    explorer 的 source 在 PUBLIC\SHELL\OAK\HPC\
    處理 Icon Cache 的 code 在 PUBLIC\SHELL\OAK\HPC\CESHELL\API\iconcache.cpp

    另外也可以看一下 SHGetFileInfo (PUBLIC\SHELL\OAK\HPC\CESHELL\API\api.cpp), 試看看假如在 get Icon 時是 UNC 就讓它傳回 Default Icon 看看是不是會改善

    -----------------------------------------------------------------------
    假如我的回答有確切的回答你的問題,請不嗇把它標示成"有用",謝謝
    • 已提議為解答 JocoboNY 2009年2月24日 上午 08:20
    • 已標示為解答 bauannModerator 2009年2月27日 下午 04:02
    2009年2月20日 上午 07:06
  • 謝謝Ellen的回復!
    另外請教:
    --->Netview command 我能查看shared folder,如何可以view shared file呢?現在的問題是open shared folder是發生此問題。
    --->我有試過explorer small icon,沒有改善。
    --->Ethernet不會出現當機,wifi-card接收數據時我是在用Thread來做,但是目前看來Thread并沒有問題(沒有包處理時會Sleep,釋放CPU)。

    您提供的關于explorer icon兩個Source Code我在看,對exe extension file发生此问题还是感到不解。

    2009年2月23日 上午 02:39
  • 可以試看看當 share folder mount to 某個 mounting point 時, 用 dir command 來 browsing 該 share
    假如這個問題該 access ICON resource 有關的話, 那很有可能是 你的 WiFi 對於小 packet access 的 performace 不佳造成的. 建意可以利用 Kernel Profiler 做 Profiling 然後分析一下這時候的 CPU time or pending 是不是在 network 這邊? 另一方面, 也可以 capture 一下 WLAN packet, 先看看是不是在 browsing Shared folder 時有很多的 small packet access?
    而雖然 WLAN Driver Thread 在 idle 時會 Sleep, 但很有可能因為 Icon Data 還沒有完全傳回來, 所以 explorer 還是 pending 在那邊

    因為 EXE file 的 ICON 都需要從 該 .EXE file 去 access, 而正好你提到只有 folder 裡有 .exe 才會有這個問題, 這似乎暗示著跟 accessing .EXE 裡的 Icon resource 有關. 此外有沒有試看看, 假如兩個 folder 裡的 file 數一樣, 但一個 .exe 比較多, 一個比較少, blocking 的時間是不是也會跟著 .exe 的數量而有某種關連?
    • 已提議為解答 JocoboNY 2009年2月24日 上午 08:20
    2009年2月23日 上午 05:52
  •  我使用net use command將shared folder map to 本機上的network目錄 ,在CMD用dir command browsing 是OK的, 但只是list exe file。 
    我曾經試圖使用Remote Profiler 分析,但是通過TCP/IP無法建立Connect,其他的Remote tools都是OK的,但是一旦打開Shared folder,調試網卡也會當掉,無法使用Remote tools,今天用KITL試一下。

    Capture packet的話看到的是XP 不停的send Retry packet,因為CE device沒有Recieve sucessful(OS 已經當機)。OS Blocking的Time是和folder中EXE file個數線性相關的,越多blocking time越長。而且第二次打開時只是顯示應用程式的Defalut Icon,并非file的本身Icon。

    剛看了API.cpp和iconcache.cpp, 在SHGetFileInfo Function通過Call iconcache.cpp中的GetImageIndex來對icon進行處理的。所以我打算在GetImageIndex中直接返回Defaluticon看下有無改善。
    SHGetFileInfo.cpp
    SHGetFileInfo()
    ...........
       // Get the icon
       if ((SHGFI_ICON | SHGFI_SYSICONINDEX) & uFlags)
       {
          psfi->iIcon = CIconCache::pIconCache->GetImageIndex(pszPath, dwFileAttributes, FALSE);
    ...........

    iconcache.cpp
    GetImageIndex()
    .............
    if (FAILED(::StringCchCopy(szTargetPath, lengthof(szTargetPath), pszFilePath)))
       {
          return GetDefaultImageIndex(pszFilePath, dwAttrib);  //Get defalut icon
       }
    // Get the target
       if (PathIsLink(pszFilePath))
       {
         ......
       }
      if ((-1 != dwAttrib) && (FILE_ATTRIBUTE_DIRECTORY & dwAttrib)) // Directory
       {
          iIndex = GetDefaultImageIndex(szTargetPath, dwAttrib);
       }
       else 
       {
          CacheInfo * pCacheInfo = GetItem(szTargetPath);          // Cached item
         ......     
       }
    在cache icon中對EXE的處理是這樣的:
    CacheItem()
      if (PathIsExe(pszFileName))
          {
             // Exes are treated differently

             // ITEM: Each exe had it's own icon, since it is pulled from the binary
             cch = _tcslen(pszFilePath)+1;
             pCacheInfo->m_pszItem = new WCHAR[cch];
             if (pCacheInfo->m_pszItem)
             {
                StringCchCopy(pCacheInfo->m_pszItem, cch, pszFilePath);
             }

             // TYPE: Pull the type information from the resources
             pCacheInfo->m_pszType = LOAD_STRING(IDS_FILETYPE_APPLICATION),
             pCacheInfo->m_fFreeType = FALSE;

             // ICON: Get the icon from the binary
             ::ExtractIconEx(pszFilePath, 0, &hiconLarge, &hiconSmall, 1);
          }


        

    2009年2月23日 上午 07:25
  • 剛才經過試驗,發現果然是load icon造成的pending,直接Call  return GetDefaultImageIndex Function,在open shared folder時不會發生blocking。
    我在以前blocking時capature了packet,發現size為100~140不等,wifi在處理small packet時可能存在著問題,下一步將著手解決這個。
    另一方面,為何CE5.0沒有相似的問題呢,對比CE5.0和6.0下這兩個文件的差異也許可以有些發現吧。
    再次多謝Ellen精準的分析!!
    2009年2月23日 上午 10:16

  • blocking packet的size為100-300不等的,在收packet時os已經hang住了。
    不過現在發現一個新的問題,我在CE6.0下可以看到移動盤里的exe file的icon,也可以看到\windows folder里面exe file 的icon,但是我從移動盤copy 一個exe file到ce系統的文件夾后,它自己的icon就丟掉了,而是顯示defalut的application icon,請教這個icon應該是os去get的,難道是copy過程中對exe 的icon出現了問題?
    謝謝了!

    2009年2月25日 上午 07:36
  • 要證明 exe 中的 icon不見了,可以寫個 AP 用 ExtractIconEx 出原來的,和Copy的 比對.
    假如沒錯,那,是否是 Explorer 的錯誤,或許,是不是有 patch沒上呢?

    Remote Profiler 無法正常的部分:其實可以用 Offline 的 Profiling (ProfileStart),Log file 事後再從 device 拷貝出來.
    2009年2月25日 上午 08:05
  • 你好,ellen。

    我寫了個AP實現讀取exe file的icon,發現可以讀出,說明copy出來的file是包含icon的info的,但是explore并沒有show出來,這個應該和explore geticon有關。

    我用remote pofiler時會彈出一個對話方塊,“Remote Call Profiler cannot connect ...required component did not download.. ”

    我已經安裝MSDN的提示,將WINCECALLCAP=1 add進來,并且enable profiling,還需要加入哪些component才可以呢?

    您所述的offline profile我沒有找到相關資源,需要哪里exe或者lib檔,可否詳細告知,謝謝!

    2009年2月27日 上午 08:33
  • 有很多方法可以做

    加上 CELOG (IMGCELOGENABLE) capture 下來的 .clg 可以拿到 desktop 來直接用 Kernel Tracker 開來看, 不需要真的有 KITL or 其它 connection http://msdn.microsoft.com/en-us/library/aa936117.aspx and http://msdn.microsoft.com/en-us/library/aa935509.aspx

    此外也可以做 profiling

    從 CE Target Control (Shell) 下 prof on/off command 到寫個小程式 invoke ProfileStart / ProfileStop 都可以辦到

     可以參考這篇 http://msdn.microsoft.com/en-us/library/aa934742.aspx

    2009年2月27日 上午 09:42
  •  Hi.ellen,抱歉剛來回復。
    最近用ProfileStart來Capture block時的狀態,設定200ms的interrupt。通過Application load 網絡共享文件icon的方式,perfalyzer celog有大Data Loss的狀況(os block造成的?)。
    ========  Data loss counter:  1850184 bytes of CeLog data lost since last counte
    r was logged ========
    ========  Data loss counter:  4257232 bytes of CeLog data lost since last counte
    r was logged ========
    ========  Data loss counter:  4261920 bytes of CeLog data lost since last counte
    r was logged ========
    ========  Data loss counter:  4188552 bytes of CeLog data lost since last counte
    r was logged ========
    ========  Data loss counter:  4233516 bytes of CeLog data lost since last counte
    r was logged ========
    ========  Data loss counter:  4270224 bytes of CeLog data lost since last counte
    r was logged ========
    ========  Data loss counter:  4213972 bytes of CeLog data lost since last counte
    r was logged ========
    hits per symbol顯示主要是kernel.dll的idle state。

    Module Hits Percent
    kernel.dll 57551 99.5
    celog.dll 86 0.1
    k.coredll.dll 69 0.1
    NK.EXE 58 0.1
    filesys.dll 17 0.0
    Profile.exe 8 0.0
    gwes.dll 8 0.0
    k.ceddk.dll 4 0.0
    ehci.dll 2 0.0
    k.spnego.dll 2 0.0
    coredll.dll 2 0.0
    tcpstk.dll 1 0.0
    explorer.exe 1 0.0
    mydriver.dll 1 0.0
    usbd.dll 1 0.0
    commctrl.dll 1 0.0
    devmgr.dll 1 0.0
    TOTAL 57813 100.0

    HITS PER SYMBOL

    Hits Percent Address Module Routine
    57451 99.4 0x802477C8 kernel.dll _IDLE_STATE
    86 0.1 0xC00719A5 celog.dll _EXT_LogData
    56 0.1 0x80228F19 NK.EXE _READ_PORT_UCHAR
    54 0.1 0xC00C9ED0 k.coredll.dll _memcpy
    43 0.1 0x8024808E kernel.dll _PROF_GetThreadName
    11 0.0 0xC010D1BA filesys.dll _FSRecordLogEntry
    8 0.0 0x80235F4F kernel.dll _Int22KCallHandler

    HITS PER THREAD

    Hits Percent hThread Thread Module Owner Process
    57453 99.4 0x00000000 Kernel Idle "Thread" NK.EXE NK.EXE
    144 0.2 0x076E07D6 celogflush.exe main thread celogflush.exe celogflush.exe
    52 0.1 0x05E80506 ?NewWindow@@YAKPAX@Z explorer.exe explorer.exe
    30 0.1 0x040C0546 _CTEpWorkerThread cxport.dll NK.EXE
    24 0.0 0x03079EBA Profile.exe main thread Profile.exe Profile.exe
    22 0.0 0x00D90006 _ndisWorkerThread ndis.dll NK.EXE
    22 0.0 0x0502001A ?Ps2MouseIsrThread@@YAKPAVPs2Mouse@@@Z kbdmouse.dll NK.EXE
    16 0.0 0x02940002 ?UsbInterruptThreadStub@CHW@@CAKPAX@Z ehci.dll NK.EXE

    我capture發現os block前收發的packet(100-300byte)都是ok的(通過對比其它方式的連接)。在收上最后一個packet送到os那里,這個packet包含共享file path的info,ceshell將調用ExtractIconEx,os就會block。對于相同size的packet我做過ping test,也是ok的,對rx部分進行修改再嘗試一下有無改善。
    謝謝您的關注!

    2009年3月6日 上午 10:59
  •  1) Profiling 跟 用 CeLogFlash 取得 .CLG 是兩回事, 利用 ProfileStart/Stop API 得到的 output 是 profiling. 兩個不要一起用, 才不會互相干擾. 所以你現在做的是 Profiling. 這時應該把 celogflush 拿掉.
    2) 做 Profiling 時假如有 Data loss, 可以考慮把 buffer 加大一點. 並且用 buffered mode.
    3) 同樣的 CeLog 有掉資料也可以把 buffer 加大 http://msdn.microsoft.com/en-us/library/aa935741.aspx and http://msdn.microsoft.com/en-us/library/aa936081.aspx
    4) 就結果看來, 大部份的 CPU time 都在  idle, 也就意為著 可能是 network protocol stack 被 blocking 住了, 這時可以試著用 CeLog (Kernel Tracker) 來看看 NDIS 還有相關的 component 是不是有被 block 住
    5) Driver 的 Rx Handler 是用 CreateThread 產生的嗎? 還是標準的 NDIS miniport ISR/InterruptHandler? 基本上假如是 NDIS miniport 的 handler, 而在其它的 handler sleep 或會造成 driver 都被 hang 住. (比如說在 CheckForHang 裡頭的那個 sleep 就是一個典型的例子)
    2009年3月6日 下午 05:43
  • Hi,之前的做法是采用profile+celog。
    參見你的建議,我單獨使用profiling,但是效果亦不是很明顯。
    Kernel Profiler: Gathering MonteCarlo data in buffered mode
    ProfileStart() : Allocated 133400 KB for Profiler Buffer (0xE0E40000)
    Starting profile timer at 200 uS rate
    Hits       Percent Address  Module           Routine
    ---------- ------- -------- ----------------:---------------------

        503937    95.6 -------- ----------------:IDLE
           464     0.0 c00b9ed0 k.coredll.dll   :_memcpy
           220     0.0 c0093766 k.coredll.dll   :___GetUserKData
           215     0.0 c0093774 k.coredll.dll   :_EnterCriticalSection
           198     0.0 80235f4f kernel.dll      :_Int22KCallHandler
           164     0.0 c00937f9 k.coredll.dll   :_LeaveCriticalSection
           126     0.0 80246139 kernel.dll      :_INTRDone
           106     0.0 c0aa1d17 ddi_via.dll     :?EmulatedBlt_Internal
            89     0.0 80235b49 kernel.dll      :_KCall
            75     0.0 80235955 kernel.dll      :_Int20SyscallHandler
            64     0.0 c039324c k.ceddk.dll     :_READ_PORT_UCHAR
            62     0.0 8023ef5c kernel.dll      :_LeaveCriticalSection
            61     0.0 c0aa6aa3 ddi_via.dll     :?EmulatedLine
            59     0.0 8023ef14 kernel.dll      :_EnterCriticalSection
            58     0.0 8024d836 kernel.dll      :_WaitOneMore
            45     0.0 80252d85 kernel.dll      :_HNDLAlloc
            42     0.0 802448c0 kernel.dll      :_memset
            41     0.0 c0093844 k.coredll.dll   :_TlsGetValue
    Capture Log中并不能明顯的看出block相關的信息。
    另外,USB是BULK IN/OUT的方式。在Rx Handle中,透過一個Thread來check是否有packet,如果存在的話就調用NDIS的function:NdisScheduleWorkItem來處理。現在是USB網卡在處理icon時NdisScheduleWorkItem并沒有callback(猜想由于os blocking,所以沒有return),我將NdisScheduleWorkItem換成Thread也沒有本質的改善。
    謝謝!
    2009年3月9日 上午 09:07
  • 就如上一篇 post 裡頭講的, 因為現在大部份 CPU time 都在 idle, 所以 Profiling 並沒有辦法幫你找到消耗掉 CPU time 的 task (因為現在跟本沒有 thread 在動), 而是要靠 CeLog 然後把 .CLG 拿到 desktop 用 KernelTracker 或是其它 ReadLog program 來分析 可能的 blocking issue, 看看是不是在 wait 某個 Sync. Object, 而這些 Sync Object 是不是又被另一個 thread 給拿走了, 而導至一些 dead lock 等. (上一篇的 3 and 4), 這時就不需要做 Profiling, 以免互相干擾.
    而你是用 USB interface (這你其實可以在一開始就先講出來), 這又讓事情梢為在複雜一點, 要分成兩部份來看
    1) USB 到 WLAN driver 這一段
    2) WLAN 到 NDIS
    首先要先釐清當有 blocking 時, USB transaction 的 receiving Thread 是不是還是正常運做 (是不是還可以正常收 packet 進來), 以釐清 USB Host controller 這邊是不是有 blocking issue.
    而假如可以的話就看 WorkItem routine 跟 NDIS 這裡頭是不是被 blocked 住了. 由於 NDIS 的 source 在一般 Sahred Source level 並沒有, 這邊就只能完全靠 CeLog (Kernel Tracker) 來 tracing, 甚至在必要時 (假如你認為就是在 NDIS 裡出了問題) 可以考慮直接跟 MSFT 聯雒, 做進一步的 debugging.
    而你將 NDIS WorkItem 換成 另外一個 thread 也沒有改善, 這兩個 thread 之間有沒有什麼 共用的 Sync. Object (Mutext, CS, SpinLock and etc) 以至於互相 blocking 住? 還是該 thread 又是被某個 NDIS function blocking 住?
    試著找出這些問題都可以幫住你釐清 root cause.
    此外假如不再另外開一個 wokItem or Thread, 而直接在你的 USB Rx Thread 裡頭, 把 packet 往上傳, 又會有怎樣的變化呢?
    2009年3月9日 下午 06:11