User to user discussion and support for UltraEdit, UEStudio, UltraCompare, and other IDM applications.

Syntax highlighting, code folding, brace matching, code indenting, and function list
8 posts Page 1 of 1
Just performed update, and using now version 64-bit UltraEdit
When opening a file from a local folder (under a local svn), UltraEdit stops responding.
Help! Need to get back to work!

What I have already tried:

  • Rebooting Windows.
  • Replacing a file with a backup file.
  • Opening a different file.
  • Changing settings like described in another thread.
  • Re-installing UltraEdit.
  • De-activating syntax handling (thought it might have been files of certain type).
  • Clearing temp folder.
  • Clearing backups.
Continued to try many things.
Current understanding is that it doesn't matter where the file is located, what size the file is, what type of line endings, what the encoding is, or what it is named. UltraEdit freezes when trying to open it.
Files of the same type, content and location open fine.

Other programs like Notepad, Wordpad, Notepad++ open the same files without any problem.

So, it seems to be a content related problem in UltraEdit only.

The "hang" is not consistent enough to call content for certain. It seems if i switch back and forth between open file tabs it eventually happens.
I'm giving up for now. I have to use alternative editor until fixed.

But I would greatly appreciate any suggestions or fixes.
So it looks like this happens only with certain files in a specific folder.

I suggest following:

Copy a file which results on opening in UltraEdit in a not responding UltraEdit to C:\Temp. Create that directory if not already existing.

Try to open the copied file in C:\Temp with UltraEdit as you usually open it.

By the way: How exactly do you open the file in UltraEdit? There are more than 10 methods to open a file in UltraEdit.

Does opening the copied file in C:\Temp also result in a not responding UltraEdit?

If the answer is no, the problem is not the file content. In this case I suggest further to delete the file in original source folder. Then copy the file from C:\Temp to original folder.

Does opening the file in original folder result again in a not responding UltraEdit or does it work now?

When it works now, the problem is most likely solved for this file and the copied file in C:\Temp as well as the folder C:\Temp can be deleted.

In this case I suggest further to open a command prompt with as administrator, run the command chkdsk C: /F and confirm that the Windows check disk tool should be scheduled for execution on next system restart. Restart Windows, wait 10 seconds until the disk check (file system integrity check) starts and wait further until it finished and Windows restarts normally. After Windows restart, open Event Viewer and search in Windows Logs in Application for an entry in column Source by Wininit which is somewhere at top of the list. This event entry contains the summary information of check disk execution and in case of detected errors also the which errors were found and hopefully fixed.

In case of opening copied file from C:\Temp results also in a not responding UltraEdit, I suggest to open Windows Task Manager and look on tab Processes how much CPU usage uedit64.exe process consumes. If it is 25% on a computer with 4 cores, UltraEdit is running obviously in an endless loop as using all power of 1 core.

In this case please kill UltraEdit process by selecting it and clicking on End Process, compress the file into a ZIP or RAR archive and send it to IDM support by email with the explanation that opening this file results in a not responding UltraEdit on your machine consuming full power of 1 core which means most likely 64-bit UltraEdit is running into an endless loop.

But when not responding UltraEdit is using nearly no CPU power or when just opening the file from original folder results in an endless running loop, it is possible that UltraEdit does not get the file access as requested by UltraEdit and this results in a long delay respectively not responding UltraEdit user interface.

In this case I suggest to download the free tool Process Monitor from Sysinternals (Microsoft) and extract the ZIP file to any local folder of your choice.

Then start Procmon.exe as administrator, select Path contains file name with extension then Include and click on button Add. Next click on button OK. Process Monitor is now running. From the last five symbols on toolbar toggle off with a click on all with exception of filing cabinet symbol with tool tip Show File System Activity.

Press Ctrl+X to clear what Process Monitor already recorded and open the file in UltraEdit which hopefully results again in a not responding user interface and wait up to 2 minutes (look on clock).

Then switch back to Process Monitor, stop capturing by pressing Ctrl+E and look from top to bottom on which processes accessed the file with which command and which type of access and what was the result.

It could be that you see that UltraEdit does not get the file access it wants according to your configuration for example because of NTFS permissions or because of specific file access denied by another process.

My last suggestion is opening the properties of the shortcut used to start UltraEdit.

On tab General check if Location of shortcut file is a directory (desktop or start menu) which belongs to your user account or or the all users account.

On tab Shortcut click on button Advanced and make sure Run as administrator is NOT checked.

On tab Compatibility make sure none of the check box options being enabled.
Best regards from Austria
Mofi, Thank you for the reply. I've delayed responding since support was looking at my issue. But, unfortunately, I haven't heard back from them in a couple of days after there initial information gathering. I suspect they are looking at the concern in hopes to provide a fix. But .. in the mean time ...

I tried your suggestions and still no joy. I've attached the process monitor log in csv format. (The log was removed later.)

Does it expose anything that you can recognize?
I have never seen before such a file system access log on opening a file with UltraEdit. I was not even aware of the Windows kernel functions QueryAttributeTagFile and CreateFileMapping. I have tried with 32-bit UE v24.00.0.76 on Windows 7 SP1 x64 to see such a file access on opening a file. But I could not find a file open method which results in execution of these functions. So I would be really interested in:

How do you open the file C:\Impact\mcs\t\

Perhaps this occurs only when file is opened via SVN. In this case I'm not able to reproduce that because of not having SVN installed at all on my machines.

After no success on reproducing the file open resulting in usage of QueryAttributeTagFile and CreateFileMapping I looked on file open of C:\Temp\

The file has a file size of 78705 bytes according to information in row 7. But on opening C:\Temp\ UltraEdit reads first just the last 408 bytes from offset 78297 as it can be seen on row 112. Why? I don't know why the file reading did not start from offset 0 with a 32 KB or 64 KB block as usual.

Was the file already opened in UltraEdit on logging the file system accesses?

I have never seen before that UltraEdit first reads just a few bytes from end of file.

I also can't see a file query which tells UltraEdit that the file C:\Temp\ has a file size of 78705 bytes. That's all very mysterious for me as I have never seen this before on analyzing UltraEdit file access logs.

Is file polling enabled for this file?

On the rows 135 and 136 it can be seen what usually happens first, the entire file contents is read by reading the first 64 KB and next the remaining bytes according to file size most likely for creating the temporary file.

Perhaps there is a problem with the temporary files creation in %TEMP%. It would be interesting to see also what file system accesses occur on temporary file. Modify the Process Monitor filter to log all file system accesses for Path contains z_vrbtst (without file extension) to get also the temporary file accesses displayed.

By the way: The board allows attaching 1 to 3 files with up to 250 KB per file being a ZIP or RAR file. That's the best method to attach a log either in native Process Monitor format or a CSV file compressed with best compression into a ZIP or RAR file.
Best regards from Austria
The above capture was done by doing a file open on c:\temp\
I didn't even try to open c:\impact\mcs\t\
c:\temp isn't a svn folder, it was newly created outside of svn.

I have tried the following methods to open my .ps files ( not just, but others too! ) :

  • right click and open with UltraEdit
  • file open
  • drag and drop into UltraEdit
In the logged instance the file was not open, at least it wasn't open and visible to me.

I'm not familiar with file polling, so don't think anything has been done to enable that for this file or the others of this type.

I have attempted to completely clear %temp% - no change in behavior.

I have un-installed UltraEdit, rebooted, re-installed - no change in behavior.

Wondering about code folding or other in content behavior features? Or perhaps the new encoding features are somehow being triggered in a problematic way?

I've tried copying a different .ps plb code file to a brand new folder and renamed it to .txt, then opened it by doing a right click. It opened fine, and I could scroll up and down. But as soon as I clicked of that file tab to a different file, it froze.
Doing the same with a non plb source code file ... and no problems.
It is really very strange what happens on your machine.

I don't think another process like an antivirus application is responsible for the not responding UE on file open or change of active file, except the antivirus application is configured to always scan all files on possible threads independent on file extension. However, if you are running an antivirus application I suggest to temporarily disable the on-access scan of the antivirus application and check if UltraEdit is still not responding on opening that file or on switching to another file.

But it looks like this issue depends really on file contents, but not on all the features associated with syntax highlighting.

Does UltraEdit consume the complete processor power of a core when UltraEdit is not responding?

That would be a very clear indication of a bug in UltraEdit which results in UltraEdit is running into an endless loop. Such an issue is usually easy to detect by a developer when having the same file and the same settings, i.e. an email is sent to IDM support with a ZIP or RAR file containing the file opened by you and best the entire directory %APPDATA%\IDMComp\UltraEdit.

Otherwise UltraEdit is waiting for something on nearly no CPU usage by not responding uedit64.exe process which can be also caused by a bug in UltraEdit (multi-thread issue), but is caused most likely by another process running in background.

I suppose that you use projects in UltraEdit and there is a project opened in UltraEdit after starting. I suggest to do following:

  1. Make sure that just one instance of UE is running by exiting all other running instances.
  2. Close the project when there is one opened. And close also all files.
  3. Open Advanced - Settings/Configuration - Toolbars / Menus - Miscellaneous, click on button Clear history and next on button Cancel.
  4. Exit UltraEdit.
  5. Open with Windows Notepad %APPDATA%\IDMComp\UltraEdit\uedit64u.ini and search for [Open Address Bar]. Remove the entire section, save the file and exit Notepad.
    (I reported some weeks ago that the file names with full path in this section are not removed on using button to clear history, just the count is set to 0 which is not enough.)
  6. Restart UltraEdit, press Ctrl+O and open that file. Use Ctrl+O a second time and open another file. Switch between the file tabs of those two files.
Does on last step occur again that UltraEdit becomes not responsive?

Yes, then I agree with your assumption that the encoding of the file in combination with all the modifications made on UltraEdit source code to became a real Unicode aware application is responsible for the hangs of UltraEdit user interface.

By the way:

Which encoding have the files which cause the non responsive UltraEdit and have the other files a different encoding?
Best regards from Austria
Yes UE is in a loop, it consumes the full 25% in the process list.

Support already has all the files, and have not been able to reproduce.

But, I have drilled down and can now duplicate with this pattern:

Starting with a new file, paste in the below:

Code: Select all
           IFZ 1
      "Seg Repeat":null,

And then save to a file with an extension that uses my syntax highlighting for this language.
So, seems to confirm content related, and perhaps syntax highlighting bug.
But, turning off syntax highlighting does not fix the problem.

And the "IFZ 1" string appears to be the pattern that somehow triggers the problem.
Other files with this pattern behave the same way. Where files of same type without this pattern do not.

Perhaps a problem with my syntax highlight file?

IFZ 1 is the start of comment block , and XIF ends it.

I removed this from my syntax highlight file:
Code: Select all
Block Comment On Alt = IFZ  Block Comment Off Alt = XIF 

and it no longer hangs!

Code: Select all
/L20"DB/C" Nocase Line Comment = . Line Comment Alt = ++ Escape Char = # Block Comment On Alt = IFZ  Block Comment Off Alt = XIF String Chars = "" File Extensions = cb io sr ps rl ERR I6 I7 I8 R6 R7 R8 S6 S7 S8 TXT SRC INC

Code: Select all
/L20"DB/C" Nocase Line Comment = . Line Comment Alt = ++ Escape Char = # String Chars = "" File Extensions = cb io sr ps rl ERR I6 I7 I8 R6 R7 R8 S6 S7 S8 TXT SRC INC

So it is definitely syntax highlighting related.
I tried to reproduce this issue with creating a file test.uew (ANSI 1252 encoded with DOS line terminators) containing just the single line posted by you with case-insensitive alternate block comment and a file test.txt (ANSI 1252 DOS) containing the posted block with 32-bit UE v24.00.0.76 with everything in configuration set to default. But I failed to reproduce the issue. The file test.txt was opened without any problem and was also correct syntax highlighted as alternate block comment although end of block comment was missing in the file. Another *.txt file not containing IFZ was also opened without any problem. And a third file with extension TMP was opened also quickly. Switching active file worked also well.

However, you have definitely found the bug. So please send the example file together with everything in %APPDATA%\IDMComp\UltraEdit including the wordfiles directory with the wordfile by email to IDM support and report what you have found out regarding running in endless loop by UltraEdit because of case-insensitive alternate block comment.

BTW: There should be only one space in wordfile after string IFZ, but that additional does not really matter. And there should be only one double quote after String Chars = . The typical string character definition is: String Chars = "'. On using just the double quote character as string begin/end character there should be only 1 double quote in the wordfile.
Best regards from Austria
8 posts Page 1 of 1