locked
WPF and Custom Credential Provider in Windows 7 RRS feed

  • Question

  • Hi there,

    I'm asking a question similar to the one in thread "WPF loads slowly on logon and switch user when launched from custom Credential Provider" (I cannot include the link for some error in this page) because I'm having exactly the same problem one and a half year later. According to the response we should give up using WPF in a custom credential provider but this is a very costly option at this moment. Additionally the said thread is from March 2013 and the situation might have changed at this moment.

    I found my custom credential provider is working great in Windows 8 and 8.1 and some platforms with Windows 7. But there are other platforms with Windows 7 where the WPF window takes 30 sec to show up. 

    During my tests I created a very simple WPF application, with the Wizard and without any custom code. I run Visual Studio from the same logon UI session and from there I debug my simple WPF application. I detected the same problem (All in a specific Windows 7 and win32 platform, .NET 4.5.1).

    From my debugging and performance anlysis, it seems the delay occurs in function

    System.Windows.Application.Run (The ETL created with Performance Analyzer shows most exclusive time is consumed here).

    According to the said thread, the problem occurs because the foreground WPF UI thread is blocked waiting for the WPF render thread (in background) which in turn is waiting for some driver to initialize hardware. 

    It seems the UI thread finally timeout because the time is exactly 30 secs.

    My question is if the response to the question mentioned above is still relevant today (October 2014) or there is already a solution to this issue.

    It would be great if Keith Fink (the same guy that worked on the other issue) could follow up on this issue.

    Thanks in advance,

    Rodolfo


    Tuesday, October 7, 2014 7:05 PM

All replies

  • Hi Rodolfo,

    What's the issue? Could you provide a sample for us to reproduce this issue?

    Thursday, October 9, 2014 2:09 AM
  •    

    Hi Demon.NET,


    Here I'm providing more details instead of a sample. Let me know if you still need a sample:

    I developed a credential provider that uses WPF and shows a Window in its UI.

    The credential provider runs in the context of logonui instead of running in the user context.

    When the method show is called for this window, there is a lapse of 30 seconds before the window appears.

    This issue does not occur in Windows 8 and 8.1 . I only witnessed it in Windows 7, in some platforms, not all. For example, I have a Lenovo T430 with Windows 7 Enterprise, SP1, 64 bits and .NET 4.5.1 and I’m not seeing the issue in this machine. But I see the issue in a Sony Vaio Touch (touch screen) with windows 7 Professional, SP1, .NET 4.5.1, 32 bits . I also saw the issue in another laptop Acer with Windows 7 (don’t remember details) that had .NET 4.5.2 and did not have the issue with .NET 4.5.1.

    At the same time I observe a process wisptis.exe is executed during those 30 seconds. During these period there are two processes wisptis.exe running.

    Definitely it is related but this doesn’t completely explain the situation.

    The said issue occurs in logonui context but NOT in user context (after I log in with my credentials).

    The following link shows a similar problem (not exactly the same): http://social.msdn.microsoft.com/Forums/vstudio/en-US/9b6e714f-afb8-4cc4-86da-40cd7531c565/wpf-loads-slowly-on-logon-and-switch-user-when-launched-from-custom-credential-provider?forum=wpf 

    In this link they point to the initialization of the Direct3 driver but this is not the case in my issue.

    In order to go deeper I created a very simple WPF application wpf_wnd2.exe. This is not the credential provider but a simple application created with VS wizard. Then, in the logonui context my credential provider opens a shell command prompt. From that command prompt, I run wpf_wnd2.exe, and it also takes 30 seconds to show up.

    I can executed the same executable file many times from the command prompt and always see the same problem of 30 seconds delay.

    I debugged the application (in my Sony Vaio touch screen) and downloaded WPF symbols and source code. In the debugging process I finally reached the line of code where the delay of 30 seconds occurs:

    -In the dll PresentationCore.dll, file PenThreadWorker.cs, function GetTabletCount is called:

        MS.Win32.Penimc.IPimcManager pimcManager = MS.Win32.Penimc.UnsafeNativeMethods.PimcManager;
        uint cTablets;
        pimcManager.GetTabletCount(out cTablets);
    See: PenThreadWorker.cs  http://referencesource.microsoft.com/#PresentationCore/src/Core/CSharp/System/Windows/Input/Stylus/PenThreadWorker.cs

    PimcManager is a COM object defined in PenImcRcw.cs

    http://referencesource.microsoft.com/#PresentationCore/src/Core/CSharp/System/Windows/Input/Stylus/PenImcRcw.cs
        ComImport,
        Guid("9bc79c93-2289-4bb5-abf4-3287fd9cae39"),
        InterfaceType(ComInterfaceType.InterfaceIsIUnknown)


    I hope this helps describe my problem. Please let me know if you need more info.



    Thanks,

    Rodolfo





    • Edited by rk_rodolk Thursday, October 9, 2014 9:54 PM
    Thursday, October 9, 2014 8:39 PM
  • Demon.NET,

    I created a console application that calls GetTabletCount using penimc.dll. When I run this application in logonui context I detect always the same issue in Windows 7.

    How can I upload the project so that you can use it?

    Thanks.

    Saturday, October 11, 2014 12:48 AM
  • Onedrive.

    Zip your stuff.

    Upload it.

    Share > View only

    Post the link.

    .

    As to your problem.

    Tricky.

    Maybe you could write your own replacement for PimcManager which you install on win 7 32 bit devices.  I have no idea how practical that would be and it sounds like hard work.

    Raise it as a bug.  If you can supply code which easily reproduces it you should have a reasonable chance of it being fixed.  It's arguably a rather obscure bug... so I dunno how long it'll take for them to get round to fixing it.

    Saturday, October 11, 2014 9:29 AM
  • Rodolfo,

    try to put in "automatic start" the "Tablet PC input service"

    We had the same issue, not (only) in the logonui context, but in all user contexts different from the main logged user. Try with a simple runas /u:xxx cmd ant then start your simple wpf_wnd2.exe program form other user's console.

    We found also that if any wpf program is already running with the logged user context, the second wpf program started from another user context starts without 30 sec. delay.

    We found also that starting one time the "screen keyboard" will solve the issue forever and then we realized that the "Tablet PC input service" was started after running screen keyboard.

    In our case, manually starting that service before any try or putting it in automatic start will solve all issues.

    HTH

    Beppe

    Tuesday, May 5, 2015 5:29 PM
  • i am having this same issue when i use WPF with .net 4.5.2 regardless of complexity of the app. A blank app with nothing on it still takes 20-30 second to load on a windows 7 machine quad core i7 3.46 with 8 gig of ram.
    I just installed .net 4.7.2 and it has drastically sped up the application start time. Hope that helps
    • Edited by Scott Jasin Tuesday, August 21, 2018 2:23 PM
    Tuesday, August 21, 2018 2:23 PM