Clarion debugger and Windows 10 Fall Creators update (1709)

ide
#1

Recently, one my projects started crashing the clarion debugger just after it loaded all the procedures. At least that is what I thought.
I wasn’t having trouble with other client projects, just this one. I started to think that my project had caught MarkG’s disease of being unable to debug.
Today, it dawned on me that this client’s virtual machine had recently upgraded to Windows 10 Fall Creators (1709).
I quickly checked my other VMs and none of them have upgraded yet and those VMs still run the debugger.
I jumped to a VM unrelated to any client with basic Clarion 10 installed that has also upgraded to Win 10 1709 and tested the DLLtutor application. It also crashes the debugger.
Based on this it appears some in the latest Win 10 is incompatible with the C10 debugger (haven’t tried other versions).
Question: Is anyone who is a regular user of the debugger using it with Win 10 ver 1709.16299.98?
Please, I know the debugger has issue but let’s not take this down the path of crapping on it.

Thanks,
Rick

#2

Works here under these versions:

I have not upgraded Clarion recently though:

Are you launching the debugger from the IDE or directly from windows explorer?

FYI in case it makes a difference - How to successfully start the debugger from the command line?

#3

Hi Brahn,

That’s same OS version as I’m using so it must be a more specific situation…

I have tried launching from both the IDE and command line with the same results.

#4

Using same ver of Win 10 on two PC’s and all C10 debugger works fine for me

#5

Hi Ted,
Do you work in virtual machines? Both of the systems I described are VMWare virtual machines.
I’m trying to figure out if that is part of it.

Rick

#6

I’m not working in Windows 10, yet, but thanks for the warning. :sunglasses:
Tell SoftVelocity or make a PTSS entry on it…

#7

Hi Carl,

I’m exchanging emails with Robert in support at SV.
No determination yet, but we’re trying to figure out the specific since it clearly works for some folks.

Rick

#8

Good to hear that SV is on it.

I have a new Win10 computer that I am just setting up, but will not be using VMs on it. Maybe (in a day or two) I can run some comparison tests for y’all?

#9

Check and see if you are running teamviewer… This breaks clarion… Stop it or uninstall it and try again…

#10

Hi Darron,

No teamvierwer running on the systems.

Thanks,
Rick

#11

Hi Darron,

I use Clarion with Teamviewer all the time as I often work from home via TV on the computers at the office. I’ve never had issues with it.

Best regards,
Arnor

#12

Absolutely affrcted me 100% switched to dwservice which is free and simpler… Check it out…

#13

The latest version of ntdll.dll, updated on 03/03/2018, has caused a problem with the Clarion Debugger - it doesn’t seem to like it and throws an error. Basically the debugger is stuffed. Has anyone else come across this?

#14

Debugger works for me here, I am on Win10 1709 and my C:\Windows\System32\ntdll.dll is dated 16/04/2018.
What error are you getting and how are you running the debugger? (From the IDE or directly from the EXE or?)

#15

image

I get the error of I run it from the IDE or the EXE. It happens as soon as the application starts.

#16

Hi Folks,

My Windows 10 updated today (was very insistent), and because I’ve never had trouble previously (in terms of Clarion + Development), I let it happen.

Am running Clarion 10.12463.

Having an incredibly hard time creating a new exe app with dictionary. Seems to be throwing exceptions at every point. If I add the dictionary and it has alias files, exception. If I try and compile with StringTheory extension, exception. Then it’ll work past that, but when I try and add a Source procedure, boom, exception.

Example (from right now).

App + Dictionary. Main (Frame) has been added, and compiles.

  1. Add StringTheory global. Compiles okay.

  2. Add a source procedure and click the save button. EXCEPTION on saving the procedure (just saving it, no code, nothing else):

Exception occurred at address 12C46BE1
Exception code C0000005: Access Violation
Process PID=12772  Image: C:\Clarion10\bin\Clarion.exe
Thread 2  Handle=00000A0C  TID=11564

Exception parameters:
00000000
00000000

EAX=00000000    EBX=157EC414    ECX=0000000E    EDX=2112BC48
ESI=2112BC48    EDI=157EC414    EBP=157EC604    ESP=157EC3D4
EIP=12C46BE1    FLG=00010287

Call Stack:
12C46BE1
12CD5B07
12CCE75B
12C9E8BF
0A9ED0D1
77CD2EC0
77CD2E90

This could be bad. I can’t update Clarion 10 for fear of SQL monsters. And presumably it’s going to be a real problem to go back to a previous windows.

Any thoughts?

My hope is that I’ve just stumbled across some Clarion 10 (the above version) peculiarity. A far hope.

EDIT #1

  1. Cleaned out the app folder.
  2. Created new app, no dictionary.
  3. Created “Main” as an MDI Frame proc.
  4. Compiled okay.
  5. Created source procedure, “Debug”. Pressing save went smoothly. No error.
  6. Compiled okay.
  7. Added the StringTheory global extension. Pressing save/okay went smoothly.
  8. Compiled okay.
  9. Added “GLO:st1 StringTheory” into a Global Data embed.
  10. Compiled okay.
  11. Added a line of code to the “Debug” source procedure, “GLO:st1.Trace(‘huzzah!’)”.
  12. Compiled okay.
  13. Called Debug() after window opened in the “Main” procedure.
  14. Compiled okay.
  15. DebugView shows the trace.

So at this point it’s pretty clear I can keep doing “non-dictionary” stuff and it will work. Maybe. But anyway.

  1. Create “app.dct”, an empty dictionary file. Save it. Close dct.
  2. Open app, go to “Global Properties” and add “app.dct” into the Dictionary File template field.
  3. Click “Actions” (previously before this testing, when using a filled dct, clicking this button would exception out). Global Properties dialog window opens okay.
  4. Go to Application Tree and save.
  5. Compiles okay.

So at this point we have an exe with a dictionary (empty), and it seems to be compiling fine.

  1. Close app and open dictionary.
  2. Add a single file with a single “Guid” field, and that field as the PK.
  3. Save and close dct. Okay at this point.
  4. Open app and compile.
  5. Compiles okay.
  6. Go to Global Properties, open dialog, go to “File Control” and tick “Generate all file declarations”. Click OK. Go back to Application Tree and compile.
  7. Compiles okay.
  8. Close app and open dct.
  9. App a “GLO” Globals entity and add a single field, “st1” which is CLASS -> StringTheory.
  10. Save and exit dct.
  11. Open app and remove the global data embed for GLO:st1.
  12. Compiles okay.
  13. Now add a browse of the tps file in the dictionary (only has a Guid field, but that’s okay). Call the browse from the main app on window opening.
  14. Compiled okay. TPS file is created in app folder as expected.

Alright. So it’s not breaking. Now we step it up a notch.

  1. Open the dct and add another global object PATH, with a single field being the name of the single file in the dct.
  2. Set the path value for the file in the dct to !PATH:.
  3. In the “ProgramSetup” global embed for the app set the global PATH: field value (i set it to just be the name of the file).
  4. Compiles okay. TPS file created in app folder as expected.
  5. Add FM3 global extension. No exception, saves okay. Compiles okay.
  6. Move the setting of the global PATH field into the FM3 init embed.
  7. In the dct, add the FM3 “Version” template field to the single tps file.
  8. App compiles fine and okay and everything. Now I’m really starting to wonder what happened previously to this (very one by one) testing.
  9. In the dct, following the FM3 rules, add a single field to the file.
  10. Add in the “ABC Defaults” global extension from Capesoft.
  11. Compiles fine. FM3 upgrade runs fine.

TL;DR - I must have been doing “too much” at once with the dct + extensions on a new app and Clarion couldn’t handle it.

TL;DR #2 - Not sure if my problems previously have anything to do with the Win 10 update (may have been coincidental).

#17

I was updated to Win10 1803 today. A simple test with people.app and the debugger is working ok. Just FYI, to add to the data points!

#18

so you are all good to go now yeah? Reads like quite the stressful saga!

#19

I have created one virtual machine with WIn10 ver 1803 and it does not have the problem with the debugger.
This was a new VM. I’m going to upgrade some of my 1709 VMs that have the problem with the debugger and see if that resolves the issue.

1 Like
#20

I upgraded one of my version 1709 virtual machines to 1803 this morning and the debugger now works. :smile:
Looks like 1803 resolves whatever the problem I was having.

1 Like