In earlier releases it was a false positive. We printed runtime error to console but app still started. Since 3100 or near it started to prevent desktop app launch and we are working on decent solution at this moment.
Got 3068 working BUT the console complains about the display thing, as you mention above.
I’ve not seen it before since I seldom use the console in the simulator but run main.lua from sublime
I didnt know the api is called after on desktop builds, thx for the link, will chek it out.
Also, thanks a lot for the help with testing RG 
I think this may be caused by something that changed between 2017.3108 and 2017.3109.
- 2017.3108 - Works fine.
- 2017.3109 - My ‘complex’ app fails with the system.* issue @anaqim mentioned.
Summary of steps,
- I first reproduced the error with 3158,
- then I started rolling back till I found a safe and working version. (There were mis-steps in this process thanks to my virus scanner).
- Finally, I started working my way forward trying versions and reading release notes along the way.
It is worth noting I didn’t see anything in the release notes that gave me a hint at the cause. So, thus far I have no idea what the source of this issue is.
Finally, I’ve spent as much time as I can today helping on this so I’ll have to turn back to business now. I hope in the interim @anqim or others can find the actual cause of this issue.
Cheers,
Ed
@Bektur, I have apps that produce the same issue and that do not have display api or any api on the config file, so the issue is more composite, in fact, perhaps not relateted to that display api at all, since even though it was reported, my app with the display api in config still ran and worked fine.
I still suspect the big win 10 update that was pushed out recently.
Not quite sure what else I can do in the matter, do let me know!
@Ed, thanks for your forensics
It would be very helpful if you created a simple demo producing this error. I could have test it on my Win 10 PC
@anaqim - You’re welcome.
@bektur & @anaqim - I agree that a simple test case to help the staff reproduce is the best-case minimum requirement, but be warned this may be one of those rare cases where the test case can’t be simplified.
I say this because I tried to reproduce this will simpler apps and couldn’t, but when I used my biggest and most complex app it just popped out. This doesn’t mean a simpler test case won’t produce it and that is definitely worth pursuing, but I also wonder if sheer size of the project might be part of the issue.
@anaqim - I encourage you to try to make the simplest test case possible for the staff, but if you get stuck after a number of tries and effort please post back. I may be able to give this more time tomorrow.
Hi,
Took Radiance and skinned it to the bone and think i found the issue, or at least how to reproduce it.
Made a light project which shows what happens with latest corona build
Something has changed in how corona accept/handle/deal with config.lua
Tip: Don’t forget to to compress to zip. Not everyone has a 7z compatible app installed. Free not, nobody likes installing extra apps they don’t normally use
Looking now…
Ah, as I suspected in my original answer. You’re accessing system.* in config.lua.
- Did you use it in config.lua?
I wonder if that is officially supported. Like you I do this on occasion, but I don’t remember ever reading it was/is supported.
I used in in the simulator during dev, but not for released apps.
If it is officially supported, then it looks like a genuine and important bug, so good catch.
Ah, bad news. That is not officially supported.
See the Important statement at top of this page:
https://docs.coronalabs.com/guide/basics/configSettings/index.html
Important
Although config.lua is a Lua file, its intention is merely to configure the app in advance of its primary functionality starting in main.lua. You should not make Lua API calls within the config.lua file or perform any actions beyond simply defining the supported tables and key-value pairs for configuration purposes.
I’ll remember about zip.
Well, it worked fine up to my recent corona upgrade so something has changed, both accessing system and display, although the latter may have been generated a warning.
I use that specific code to read a folder tag which tells the system if it shold run at 30 or 60fps.
Very useful if you want to let the user choose fps from within your program.
There was a post sometime ago regarding an optimized config file, which i read and found useful and ut uses the display api, again with success, up until now.
I hope someone at staff can tell me more, now that it has been narrowed down to the config file and is likely about accessing api from there. Hate to nag, but it was working fine, so what broke it?
Yes i was reading that one but it says “should not” which is perhaps a bit vague when the internet is full of examples on how to use it this way, and it works 
I found this recent post by Rob that confirm my assumption that something happened internally which caused this issue.
Annyoing as it is, i’ll find a way around it.
https://forums.coronalabs.com/topic/70029-corona-ultimate-config-lua-file/?p=364906
Some more info:
I updated to the latest stable release, which is when this new error occured.
I then tried the latest daily build 3158 but the issue reiman.
I’ve tried to comment out anything in config and code I could think of to try and find the trigger, but no luck.
I then tried to make a win32 build of my current released version of Radiance, which is win32 and macos only, and got this:
13:50:44.052 ERROR: Runtime error
13:50:44.052 ?:0: attempt to index global ‘system’ (a nil value)
13:50:44.052 stack traceback:
13:50:44.052 ?: in main chunk
13:50:49.102 Application closed with exit code: -1073741819
Something is clearly funky.
I need to clarify one thing, the errors do not occur when building the app, but when I try to run the exe.
-
Have you tracked down the first point you try to use system.* functions or fields?
-
Did you use it in config.lua?
-
How about a basic test app, does anything work or is this specific to your app?
-
Re: display. “display is a global in all apps, it is the display.* library hook.” This is weird sounding, like Corona hasn’t fully initialized before trying to run your code.
I’ll install 3158 a bit later and try building some stuff to help dig into this.
I ran some experiments and this is what I have so far:
-
I installed 3158 on my Windows 10 machine.
-
I built and ran three different apps with these results:
- Widget Demo (comes with Corona) - WORKED
- Random Small App of My Own (uses SSK2) - WORKED
- Biggest and Most Complicated Project I Have (Multi-user Cloud Connected Storybook Editor for client). - FAILED with similar ‘system’ error message.
What this means, I don’t know. I’ll roll back a few versions till this stops happening and see when this starts occuring.
@anaqim You should do this too. Find the last working version of Corona. This will help identify the change or changes that are related ted this problem.
Hi,
I’ve tried several projects that was working win32 builds and none work after the update, so i was kind of hoping someone else could verify the same issue, before I start to look for a reasons in my code(s). To me its pretty clear something has changed. My previous working corona build was the previous stable version (i prefer stable version unless i must have/fix something)
Yes I always use config.lua, pretty basic stuff.
Checked the build files as well.
I just tried the “hello world” project and behold it worked fine as a win32 build.
Sigh, so the big question the is, what changed and made something in my code(s) incompat…
Anyone else, experiencing this with any apps?
Anaqim
Hi again, I’ll do so but my internet is very slow so it will take some time.
Will get back with the results.
I rolled back to 3130 and still have the same failure, so I went way back to 3059 and this is more promising, however as is won’t to happen when debugging I encountered a new issue.
Continuing to investigate.
3120 has the same error