Only blank white screen sometimes appears. Please advise

0
0

Hello Wisej team,

 

I have an issue that sometimes blank white screen may appear when webapp gets loaded for the first time (After IIS app reset, or on a first run). So there’s a only default loading wheel shown for few seconds.

The major issue is that I cannot understand the reason why its happening, if have no ideas on it, maybe you can suggest on how to trace more logs or any ideas where to search for a root cause?

More details:

1. When its happening, I noticed that Load events in controls is fired fine, no errors in Event Viewer or browser DevTools-Console. But(!) Appear event in such a cases is not fired, while its usually does.

2. Another strange thing I discovered that in order to reproduce the issue (apart from restarting IIS app) is – you enter URL and once you pressed enter to load the url – quickly focus on other application (just press somewhere on other screen, not browser). Otherwise, I couldn’t ever reproduce it if I stay focused on this tab. Because of this it makes me think that there’s a slight chance that Wisej code behaviours differently in such a scenario

Usually I can reproduce the issue 1 in 5 times or so, but it’s a lot in a large scale.

 

Unfortunately, I couldn’t reproduce the issue in newly created application to share with you, so likely there’s an error at my side, but I would appreciate advise on how to detect it. There’re lot of try-catches in many Load events (some are async) and so on, but still in case of unhadled exceptions it shouldn’t cause such a behaviour usually.

 

Let me know if you need any more details.

 

Regards, Michael

  • You must to post comments
0
0

Luca,

Thanks for suggestions! Debugger was configured fine but JustMyCode was enabled, I’ve disabled it. Nevertheless I gave up reproducing the issue in debug mode, as it appears very very rarely. Only sometimes I can see it in test environment (dev server, hosted in IIS, release mode..). Strangely, when compilation debug=”true” and app running in IIS (release or debug mode) stack trace is still empty (and WisejCore.debugMode is false as well)!

However, it might not matter any much as I found the code line which causes it – loginCtrl?.Dispose(); which is called at some point in loginCtrl.Load event (when we auto log in a user and want to dispose loginCtrl to free up a resources) – please let me know if there’re better practices to do it. Do I need to remove it from its parent first? Can it cause such an issue when running in non-user context (other thread)? Maybe Wisej dev team can review if Wisej UserContol/Control may have any null reference leaks?

(logincCtrl itself or its subcontrols have no custom Disposed events attached)

 

UPDATE, solution found: Once I wrapped it in Application.Update and added Controls.Remove(loginCtrl);

It started to work fine it seems. So instead of loginCtrl?.Dispose(); code looks like following now:

Application.Update(this, () =>
{
if (loginCtrl != null)
{
if (Controls.Contains(loginCtrl))
{
Controls.Remove(loginCtrl);
}
loginCtrl.Dispose();
loginCtrl = null;
}
});

So it’s likely something inside .Dispose() at Wisej side may cause null reference errors

  • Luca (ITG)
    Where exactly to you call loginCtrl.Dispose(), inside logiCtrl.OnLoad()?
  • Luca (ITG)
    Also, you can deploy on IIS and have debug mode in web.config set to true. It must set the stack trace. I tried all sorts of combinations with Load and a child dispose on Load and on a user control but don’t get any exceptions. What do you mean it’s done in a different thread, are you using Application.StartTask()?
  • Michael M
    1. Our QA confirmed the issue has been resolved after I changed to mentioned code, so we need to Dispose user controls in Application.Update(this,…) and remove from its parent first. 2. Debug mode was set to true and deployed, still no stack trace in that scenario – that’s what I meant. 3. In Load() we have some authentication flow that logs user in automatically in some cases, but as I mentioned the issue appeared only first time after IIS app restart and far from every time. 4. different thread – ah, sorry, no, just plenty of async/awaits. P.S. We’ve been having this white screen issue for a while, like for a year or so, but never payed any much attention on it as it appeared very randomly and rarely, but recently we started to have it a bit more often which might be visible for new customers. P.S.2. That was really odd bug, I’ve been working with Wisej since very beginning never seen something similar before…
  • Luca (ITG)
    Thanks. To me it sounds like a GC issue collecting a callback method which is very hard to debug without a stack trace. If you find it again or have any more info please contact us directly at support at iceteagroup.com.
  • You must to post comments
0
0

If you enable the exceptions in VS and turn off “Just My Code” it will break exactly at the line of code that throws the exception. See screenshots attached. If it doesn’t break it means it’s not set up correctly.

Debug mode is turned in web.config

<system.web>
<compilation debug=”true” />

When that is on Wisej sends back the entire stack trace. In your screen shot it’s empty. Also the exception sent back should be displayed on the screen. Since it doesn’t there is something else wrong. Can you send me a link privately at support at wisej.com that I can try?

 

Attachment
  • You must to post comments
0
0

Following up for visibility. Replied in a comment section

 

UPDATE:

Once I added Application.CurrentDomain.FirstChanceException handler in WiseJ app, I can see what server side errors appears when this issue reproduced.
There’re 2 errors thrown: (my logger looks like: Log(“CurrentDomain_FirstChanceException error:” + e.Exception.ToString());

  1. CurrentDomain_FirstChanceException error: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: Cannot perform runtime binding on a null reference
    at Microsoft.CSharp.RuntimeBinder.RuntimeBinder.BindProperty(DynamicMetaObjectBinder payload, ArgumentObject argument, LocalVariableSymbol local, EXPR optionalIndexerArguments, Boolean fEventsPermitted)
  2. CurrentDomain_FirstChanceException error: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: Cannot perform runtime binding on a null reference
    at CallSite.Target(Closure , CallSite , Object )

 

Unfortunately, the stack trace looks quite poorly 🙁

  • You must to post comments
0
0

The exception is coming from the server but the stackTrace is “” because it’s not in debug mode. If you enable debug mode in web.config you will get the stack trace. Can you send that to me please?

  • Michael M
    Do you mean by that in system.web add … or how? if so, it was already set to true there but Wisej.Core.debugMode is false
  • You must to post comments
0
0

I’ve done some code changes that could help to resolve the issue., will need to do more comprehensive testing to ensure the issue is actually resolved. I will keep this thread updated with results

Update: ignore it, the issue still could be reproduced 🙁

  • You must to post comments
0
0

Small update (see previous comment first):

Not sure if it helps, but when I stopped in Chrome debug on that error I can also see some Wisej internal process response object. See screenshot attached and if needed more expanded view of this processRepose in txt file (inside zip)

  • You must to post comments
0
0

Yeah, it happens in Chrome with both IIS express (in debug) or IIS and in both debug and release environments. Locally and on deployment server (which use IIS to serve the app). WiseJ version used – 2.1.75
– I can’t see any/catch any exceptions, neither nothing related in Event Viewer (any severe errors would be seen there).
– I would exclude assembly loading error as by logging I can see that controls are loaded fine, load event are fired, it even happens on our auto-login – I can see by logs that auto-login processed fine in the code. So it overcomes loading stage it seems.
– As for “In VS look at the View->Output-Debug”, just tried – when it reproduced Output-Debug is totally empty, not a single line there! (and obviously tons of them when it’s loaded fine).

BUT I’ve just added Wisej.onException event with simple console.log(..) and error started to appear there (see attached screenshot): {message: “Cannot perform runtime binding on a null reference”, stackTrace: “”, exception: “Microsoft.CSharp.RuntimeBinder.RuntimeBinderException”, invalidSession: false}

 

Do you have any ideas how to find the source of such a null reference error?

  • You must to post comments
0
0

When the exceptions are enabled (and Enable Just My Code is off in tools->options, which is the default usually) VS breaks on handled internal exceptions too. At the start you should get a few initial permission exceptions, loading exceptions, etc. If there is an internal exception that causes the blank screen it would break in VS.

Other things to try:

  • Use Chrome
  • Use IIS Express from VS (does it happen only with IIS?)
  • Does it happen in debug mode? Can you attach VS to IIS and when attached do you still get the problem?
  • Does it happen on different clients?
  • In VS look at the View->Output-Debug window to see if there is warning logged internally by Wisej
  • If it happens after a IIS reset it’s possibly an assembly loading error
  • What version of Wisej?
  • Another  thing to try, open Chrome, open dev tools, go o Network tab and then try to reproduce and see what communication is truncated.

I tried the scenario you mentioned but cannot reproduce. The fact that the appear event is not fired is normal since the widgets are not created on the client. If the widgets are not created it must be because the response was not received, which you can see in the Network tab. Try also to disable WebSocket in default.json.

Let me know.

 

  • You must to post comments
0
0

Any updates on that?

 

  • You must to post comments
0
0

It’s definitely has been enabled. If case of code error it would be easily reproducible, but the fact that it requires to change focus from the browser tab to something else (not every time though; see initial comment) makes me think that possibly something may prevent the UI from being updated on WiseJ side. Can it be possible? Any ideas on that?

  • You must to post comments
0
0

Enable all managed exceptions in VS Debug->Windows->ExceptionSettings; ignore the exceptions coming from the system (hit continue) and see if there is an exception when loading your app. If the exception occurs during loading it’s impossible for the server to send any info back to the browser.

  • You must to post comments
Showing 11 results
Your Answer

Please first to submit.