| Product: | PowerBuilder | Category: | Other |
| Version: | 2017 R2 | Publishing: | Public |
| Status: | Verifying | Priority: | P3 |
| Classification: | Resolution: |
Hi Benton, 1. We’d suggest you to comment out the code related to "Edit.IMEMode property". 2. We’d suggest you to try to comment out the inheritance code of all events and the code of the local events of the crashed datawindow one by one to locate the event that goes wrong and it’s location. 3. We understand you situation, however there’s not a better way to narrow it down currently before we can reproduce it on our side. Given the large amount of the code, it is truly impossible to move forward with further analysis to locate the problem unless we can reproduce it on our side. Thanks for your understanding. Regards, Mark Lee
Hi Benton, 1. We’d suggest you to comment out the code related to "Edit.IMEMode property". 2. We’d suggest you to try to comment out the inheritance code of all events and the code of the local events of the crashed datawindow one by one to locate the event that goes wrong and it’s location. 3. We understand you situation, however there’s not a better way to narrow it down currently before we can reproduce it on our side. Given the large amount of the code, it is truly impossible to move forward with further analysis to locate the problem unless we can reproduce it on our side. Thanks for your understanding. Regards, Mark Lee
Hi Mark, I did not find the IMESetMode method in our code but the Edit.IMEMode property was found in several datawindow objects within the 2017 PFC-layer pibbles. However, I don't think these dw objects were used before the crash. If the Edit.IMEMode property is not specified, does the PB2017 runtime use the default value of "0" (No Control)? What would happen if I set Edit.IMEMode to either "2" (Off) or "3" (Disable) in each column within a dw object? Note: we are not using Japanese PowerBuilder. If I could isolate the code to reproduce the crash, I wouldn't hesitate to send it to you.
Hi Mark, I did not find the IMESetMode method in our code but the Edit.IMEMode property was found in several datawindow objects within the 2017 PFC-layer pibbles. However, I don't think these dw objects were used before the crash. If the Edit.IMEMode property is not specified, does the PB2017 runtime use the default value of "0" (No Control)? What would happen if I set Edit.IMEMode to either "2" (Off) or "3" (Disable) in each column within a dw object? Note: we are not using Japanese PowerBuilder. If I could isolate the code to reproduce the crash, I wouldn't hesitate to send it to you.
Sorry for typo. We tried again to simulate the situation but still we are NOT able to locate the problem. Is there a IMESetMode method used in your code or is there any code to modify the Edit.IMEMode property setting in the column in the datawindow? All editable columns in the datawindow may trigger the call event of this MSCTF.DLL. It's hard to locate the problem without reproducing it on our side, so kindly please help to provide us a test case to reproduce it for further analysis and study.
Sorry for typo. We tried again to simulate the situation but still we are NOT able to locate the problem. Is there a IMESetMode method used in your code or is there any code to modify the Edit.IMEMode property setting in the column in the datawindow? All editable columns in the datawindow may trigger the call event of this MSCTF.DLL. It's hard to locate the problem without reproducing it on our side, so kindly please help to provide us a test case to reproduce it for further analysis and study.
Hi Benton, We tried again to simulate the situation but still we are able to locate the problem. Is there a IMESetMode method used in your code or is there any code to modify the Edit.IMEMode property setting in the column in the datawindow? All edit columns in the datawindow may trigger the call event of this MSCTF.DLL. It's hard to locate the problem without reproducing it on our side, so kindly please help to provide us a test case to reproduce it for further analysis and study. Regards, Mark Lee
Hi Benton, We tried again to simulate the situation but still we are able to locate the problem. Is there a IMESetMode method used in your code or is there any code to modify the Edit.IMEMode property setting in the column in the datawindow? All edit columns in the datawindow may trigger the call event of this MSCTF.DLL. It's hard to locate the problem without reproducing it on our side, so kindly please help to provide us a test case to reproduce it for further analysis and study. Regards, Mark Lee
Hi Mark, I hate to sound like a broken record. For some windows, we do have code in the datawindow itemfocuschanged event or similar events. However, we don't call MSCTF.DLL directly. So what specific PowerScript built-in functions should I pay particular attention to that will ultimately call or be impacted by the MSCTF.DLL?
Hi Mark, I hate to sound like a broken record. For some windows, we do have code in the datawindow itemfocuschanged event or similar events. However, we don't call MSCTF.DLL directly. So what specific PowerScript built-in functions should I pay particular attention to that will ultimately call or be impacted by the MSCTF.DLL?
Hi Benton, No. We created a simple test case to simulate your case but it doesn’t reproduce the issue. Based on our analysis of your code, we suspect that when you click on the DataWindow column, you have some code trigger the switching of the Windows input method, which leads to the issue. But we are not 100% sure whether this is the case as your DataWindow is very complicated and we can’t reproduce it on our side. Please verify your code and see if this is the cause. Regards, Mark Lee
Hi Benton, No. We created a simple test case to simulate your case but it doesn’t reproduce the issue. Based on our analysis of your code, we suspect that when you click on the DataWindow column, you have some code trigger the switching of the Windows input method, which leads to the issue. But we are not 100% sure whether this is the case as your DataWindow is very complicated and we can’t reproduce it on our side. Please verify your code and see if this is the cause. Regards, Mark Lee
Hi Mark, Based on your previous comments, does this mean that the SetInputScope in MSCTF.DLL is called whenever a datawindow column receives focus to set the appropriate data type for display and data entry? I am unable to send you sample code to recreate the problem because I have yet to isolate the offending code that likely leads to the random crash. However, I can generate pbdebug files for successful and failed runs of the executable. What is interesting is that the dbg file for a crash always terminates after the button clicked event had completed its processing and before new data entry or a new button click has started. It suggests that something happens when the window is ready to refresh the screen. Do you wish to examine these pbdebug files? I warn you that there is a significant amount of output from code that existed since PB5 from over 20 years ago customized for this specific firm (and probably looks unintelligible to someone from the outside). I already compared the output from a successful button click to a crash-resulting button click and found no discernible differences. I am continuing to investigate. Can you comment on my initial question about SetInputScope?
Hi Mark, Based on your previous comments, does this mean that the SetInputScope in MSCTF.DLL is called whenever a datawindow column receives focus to set the appropriate data type for display and data entry? I am unable to send you sample code to recreate the problem because I have yet to isolate the offending code that likely leads to the random crash. However, I can generate pbdebug files for successful and failed runs of the executable. What is interesting is that the dbg file for a crash always terminates after the button clicked event had completed its processing and before new data entry or a new button click has started. It suggests that something happens when the window is ready to refresh the screen. Do you wish to examine these pbdebug files? I warn you that there is a significant amount of output from code that existed since PB5 from over 20 years ago customized for this specific firm (and probably looks unintelligible to someone from the outside). I already compared the output from a successful button click to a crash-resulting button click and found no discernible differences. I am continuing to investigate. Can you comment on my initial question about SetInputScope?
Hi Benton, Thanks for reporting this problem. This is probably caused by setting the valid scope for the column data type in DataWindow. In other words, it’s probably caused by the calling the SetInputScope method of the MSCTF.dll. Please understand that we can only be sure after we reproduced it on our side. So if possible kindly please provide a test case (PB sample) further verify this. Many thanks in advance. Regards, Mark Lee
Hi Benton, Thanks for reporting this problem. This is probably caused by setting the valid scope for the column data type in DataWindow. In other words, it’s probably caused by the calling the SetInputScope method of the MSCTF.dll. Please understand that we can only be sure after we reproduced it on our side. So if possible kindly please provide a test case (PB sample) further verify this. Many thanks in advance. Regards, Mark Lee
Hi Benton; I will now turn this ticket over to the main Support/Engineering team for their input into this weird crash in a Microsoft DLL. Mayne they can sehd some light into this random crash. I should point out that Appeon has now released PB2017R3 as well as MR01 for R3. The R2 edition is not a long term supported edition whereas R3 is. If you get a chance, you might want to consider upgrading to the latest Appeon PB version to get long term fixes. I will defer your question on the use of "MSCTF.DLL" for SLE Control and/or DW Column data entry support to the Engineering team. They should be able to answer this specific question after looking at the underlying PB run-time code. Regards ... Chris
Hi Benton; I will now turn this ticket over to the main Support/Engineering team for their input into this weird crash in a Microsoft DLL. Mayne they can sehd some light into this random crash. I should point out that Appeon has now released PB2017R3 as well as MR01 for R3. The R2 edition is not a long term supported edition whereas R3 is. If you get a chance, you might want to consider upgrading to the latest Appeon PB version to get long term fixes. I will defer your question on the use of "MSCTF.DLL" for SLE Control and/or DW Column data entry support to the Engineering team. They should be able to answer this specific question after looking at the underlying PB run-time code. Regards ... Chris
Hi Chris, For our PB2017 R2 Build 1756 application that was migrated from PB12, we had already swapped in the latest PFC-2017 from GitHub last year. As for PB2017 R3 Build 1880, I rebuilt the 32-bit pcode exe/pbd's using that release and tested again on Win10 64-bit. The "random" crash still occurred on MSCTF.DLL with the same exception code and fault offset as seen in the Windows Event Viewer. Faulting application name: otp.exe, version: 17.0.0.0, time stamp: 0x5c4c46f1 Faulting module name: MSCTF.dll, version: 10.0.16299.696, time stamp: 0x702fea3a Exception code: 0xc0000005 Fault offset: 0x00056ddf Faulting process id: 0x2d48 Faulting application start time: 0x01d4c237476012a0 Faulting application path: C:\Users\Public\pbntpa\UATT\OTP\exe_pb17\otp.exe Faulting module path: C:\WINDOWS\System32\MSCTF.dll Report Id: d2e9cb9e-241e-4fe5-850e-542a00966371 Faulting package full name: Faulting package-relative application ID: As I mentioned previously, it's "random" in that entering equivalent input data into the datawindow control on this window doesn't always cause the crash but it happens enough that it is noticeable. As suggested by the Eclipse team, they believe it was correlated to setting focus on a text control in a dialog window that was closing. Getting back to my original question, is PowerBuilder 2017 also using the MSCTF.DLL for data entry into textboxes (standalone or within a datawindow) and that I should pay very close attention to any code that performs setfocus(), setrow(), or setcolumn() as well key events?
Hi Chris, For our PB2017 R2 Build 1756 application that was migrated from PB12, we had already swapped in the latest PFC-2017 from GitHub last year. As for PB2017 R3 Build 1880, I rebuilt the 32-bit pcode exe/pbd's using that release and tested again on Win10 64-bit. The "random" crash still occurred on MSCTF.DLL with the same exception code and fault offset as seen in the Windows Event Viewer. Faulting application name: otp.exe, version: 17.0.0.0, time stamp: 0x5c4c46f1 Faulting module name: MSCTF.dll, version: 10.0.16299.696, time stamp: 0x702fea3a Exception code: 0xc0000005 Fault offset: 0x00056ddf Faulting process id: 0x2d48 Faulting application start time: 0x01d4c237476012a0 Faulting application path: C:\Users\Public\pbntpa\UATT\OTP\exe_pb17\otp.exe Faulting module path: C:\WINDOWS\System32\MSCTF.dll Report Id: d2e9cb9e-241e-4fe5-850e-542a00966371 Faulting package full name: Faulting package-relative application ID: As I mentioned previously, it's "random" in that entering equivalent input data into the datawindow control on this window doesn't always cause the crash but it happens enough that it is noticeable. As suggested by the Eclipse team, they believe it was correlated to setting focus on a text control in a dialog window that was closing. Getting back to my original question, is PowerBuilder 2017 also using the MSCTF.DLL for data entry into textboxes (standalone or within a datawindow) and that I should pay very close attention to any code that performs setfocus(), setrow(), or setcolumn() as well key events?
Hi Benton; I have never seen any other PB customer report a crash in the MSCTF.dll. So this is an unusual case indeed. BTW: Did you ... 1) Update your PFC layer to the PB 2017 version? https://github.com/OpenSourcePFCLibraries 2) Try using PB2017R3 (LTS edition)? R2 has no long term support. FYI: We just released PB2017R3 MR01 last week as well. https://www.appeon.com/company/news/powerbuilder-2017-r3-mr-1880-released.html Regards ... Chris
Hi Benton; I have never seen any other PB customer report a crash in the MSCTF.dll. So this is an unusual case indeed. BTW: Did you ... 1) Update your PFC layer to the PB 2017 version? https://github.com/OpenSourcePFCLibraries 2) Try using PB2017R3 (LTS edition)? R2 has no long term support. FYI: We just released PB2017R3 MR01 last week as well. https://www.appeon.com/company/news/powerbuilder-2017-r3-mr-1880-released.html Regards ... Chris
Hi Chris, Based on that eclipse bug, are you suggesting that msctf.dll is related to PowerBuilder's handling of an textbox control within a datawindow? Most of my crashes occurred after the user clicked on a button to process input data from the datawindow control. Unlike the eclipse bug, the window was not in the process of being closed. On the other hand, the processing code may modify the values of datawindow control fields and/or set focus to them depending on the logic. Is that where I should focus my attention with regards to msctf.dll?
Hi Chris, Based on that eclipse bug, are you suggesting that msctf.dll is related to PowerBuilder's handling of an textbox control within a datawindow? Most of my crashes occurred after the user clicked on a button to process input data from the datawindow control. Unlike the eclipse bug, the window was not in the process of being closed. On the other hand, the processing code may modify the values of datawindow control fields and/or set focus to them depending on the logic. Is that where I should focus my attention with regards to msctf.dll?
Hi Benton; Sounds very strange and similar to this developer's experience ... https://bugs.eclipse.org/bugs/show_bug.cgi?id=536735 Regards ... Chris
Hi Benton; Sounds very strange and similar to this developer's experience ... https://bugs.eclipse.org/bugs/show_bug.cgi?id=536735 Regards ... Chris
*Phenomenon: I migrated a PB12 32-bit application to PB2017 R2 32-bit. On Win10, the PB12 version runs okay while the PB2017 R2 version will occasionally crash (not all the time but frequent enough to warrant stability concerns). The crashes are somewhat random because the same input data for the window will work on a restart of the app. Since this is a PFC 2017 application with our own additional customizations along with environmental settings to consider, I'm not expecting an answer from you on why it's crashing. Instead, I want to know why the PB2017 runtime references the MSCTF.DLL? If I know that, I could better isolate the part of the source code that is likely causing the crash. Here's the crash information from the Win10 event viewer. Otp.exe is the PB2017 R2 32-bit pcode app and its source code does not reference the MSCTF.DLL. There's a possibility that MSCTF.DLL is used by a module other than the PB2017 runtime dll's but I wanted to check the PB2017 runtime first. Hence, my question to you. Faulting application name: otp.exe, version: 17.0.0.0, time stamp: 0x5a5f6d83 Faulting module name: MSCTF.dll, version: 10.0.16299.696, time stamp: 0x702fea3a Exception code: 0xc0000005 Fault offset: 0x00056ddf Faulting process id: 0x45c8 Faulting application start time: 0x01d4b9992fb517b3 Faulting application path: C:\Users\Public\pbntpa\UATT\OTP\exe_pb17\otp.exe Faulting module path: C:\WINDOWS\System32\MSCTF.dll Report Id: 2d8a4846-b959-4e1f-93df-edcba67bcb5e Faulting package full name: *Reproduce Steps: Remarks:
*Phenomenon: I migrated a PB12 32-bit application to PB2017 R2 32-bit. On Win10, the PB12 version runs okay while the PB2017 R2 version will occasionally crash (not all the time but frequent enough to warrant stability concerns). The crashes are somewhat random because the same input data for the window will work on a restart of the app. Since this is a PFC 2017 application with our own additional customizations along with environmental settings to consider, I'm not expecting an answer from you on why it's crashing. Instead, I want to know why the PB2017 runtime references the MSCTF.DLL? If I know that, I could better isolate the part of the source code that is likely causing the crash. Here's the crash information from the Win10 event viewer. Otp.exe is the PB2017 R2 32-bit pcode app and its source code does not reference the MSCTF.DLL. There's a possibility that MSCTF.DLL is used by a module other than the PB2017 runtime dll's but I wanted to check the PB2017 runtime first. Hence, my question to you. Faulting application name: otp.exe, version: 17.0.0.0, time stamp: 0x5a5f6d83 Faulting module name: MSCTF.dll, version: 10.0.16299.696, time stamp: 0x702fea3a Exception code: 0xc0000005 Fault offset: 0x00056ddf Faulting process id: 0x45c8 Faulting application start time: 0x01d4b9992fb517b3 Faulting application path: C:\Users\Public\pbntpa\UATT\OTP\exe_pb17\otp.exe Faulting module path: C:\WINDOWS\System32\MSCTF.dll Report Id: 2d8a4846-b959-4e1f-93df-edcba67bcb5e Faulting package full name: *Reproduce Steps: Remarks:
